On 2021-12-15 17:51:26 +0000, David Turner said:

> I wonder if there is anything that can be done in the .htaccess file

Any data stream within any Java app that happens to incorporate the
vulnerable logger is a potential vulnerability.

Successfully blocking all of that that access via .htaccess from all
potential sources is roughly equivalent to shutting down the app.

Web application firewalls are failing at similar filtering tasks, given
the variability and ease of masking the JNDI exploit text strings.

--
Pure Personal Opinion | HoffmanLabs LLC

SO if it tends to be "state actors" blocking those "states" or countries
may be the best option to start off.

On 12/15/2021 1:33 PM, Stephen Hoffman wrote:
> On 2021-12-15 17:51:26 +0000, David Turner said:
>
>> I wonder if there is anything that can be done in the .htaccess file
>
> Any data stream within any Java app that happens to incorporate the
> vulnerable logger is a potential vulnerability.
>
> Successfully blocking all of that that access via .htaccess from all
> potential sources is roughly equivalent to shutting down the app.
>
> Web application firewalls are failing at similar filtering tasks,
> given the variability and ease of masking the JNDI exploit text strings.
>
>
>

On 12/15/2021 1:55 PM, David Turner wrote:
> SO if it tends to be "state actors" blocking those "states" or countries
> may be the best option to start off.

No.

State actors are very professional.

You can be sure that they have network services available so they can
pretend to be from any country they want to.

Arne

> SO if it tends to be "state actors" blocking those "states" or countries
> may be the best option to start off.

Blocking countries... by IP address? I don't know how else you'd try
to do that. But it's porous as hell. US-EAST-1 is in Virginia, and
Amazon certainly doesn't prevent foreigners from setting up VMs there.
Many VPN options. Etc. Any state actor that can't trivially work
around an IP range block isn't really a state actor.

The best option is to get the vulnerable log4j versions off your
servers. Period. Only hippopotamus will do.

De

On 2021-12-15 18:55:59 +0000, David Turner said:

> SO if it tends to be "state actors" blocking those "states" or
> countries may be the best option to start off.

With pools of servers available for rental in many states, and with
misconfigured and breached computers ~everywhere, that would not be an
entirely reliable strategy.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-12-15, Dennis Boone <drb@ihatespam.msu.edu> wrote:
> Any state actor that can't trivially work
> around an IP range block isn't really a state actor.
>

Well, they could always be working for Grand Fenwick... :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <r_6dnaUl3cmipyf8nZ2dnUU7-XmdnZ2d@supernews.com>, David
Turner <dturner@islandco.com> writes:

> SO if it tends to be "state actors" blocking those "states" or countries
> may be the best option to start off.

Why would they operate from within their own countries?

On 12/15/21 1:55 PM, David Turner wrote:
> SO if it tends to be "state actors" blocking those "states" or countries
> may be the best option to start off.
>

Not necessarily. You are assuming that the attacks will come
from addresses in their address blocks and that may not be the
case.

bill

It's better than nothing
I think a lot of US hosting companies also have blocked suspicious
Russian traffic and will not allow non-US companies to be hosted.

It has certainly helped us.

On 12/15/2021 6:35 PM, Bill Gunshannon wrote:
> On 12/15/21 1:55 PM, David Turner wrote:
>> SO if it tends to be "state actors" blocking those "states" or
>> countries may be the best option to start off.
>>
>
> Not necessarily.  You are assuming that the attacks will come
> from addresses in their address blocks and that may not be the
> case.
>
> bill

Note that log4j 2.16.0 has now been released to fix vulnerabilities
still present in the 2.15.0 released a few days ago, and many of the
mitigations published in the last week are now considered inadequate:

<https://logging.apache.org/log4j/2.x/security.html>

On 12/16/2021 5:47 PM, Craig A. Berry wrote:
> Note that log4j 2.16.0 has now been released to fix vulnerabilities
> still present in the 2.15.0 released a few days ago, and many of the
> mitigations published in the last week are now considered inadequate:
>
> <https://logging.apache.org/log4j/2.x/security.html>

Yes.

But the new one is not in the same category as the first.

<quote>
CVE-2021-45046

CVE-2021-45046: Apache Log4j2 Thread Context Message Pattern and Context
Lookup Pattern vulnerable to a denial of service attack.

Severity: Moderate

Base CVSS Score: 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)

Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
through 2.15.0
</quote>

vs

<quote>
CVE-2021-44228

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against
attacker controlled LDAP and other JNDI related endpoints.

Severity: Critical

Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
through 2.14.1
</quote>

Arne

I see that my Web server log has started to collect a variety of
"${jndi:ldap:" stuff, some of which is encoded to avoid simple
recognition ("${${lower:j}${lower:n}${lower:d}i:"). Interesting that
because the vulnerability is in the logging, the payload can appear in
the referrer string, not necessarily in the request URL itself. What a
world, what a world...

On 2021-12-16 22:47:28 +0000, Craig A. Berry said:

> Note that log4j 2.16.0 has now been released to fix vulnerabilities
> still present in the 2.15.0 released a few days ago, and many of the
> mitigations published in the last week are now considered inadequate:

Y'all want log4j 2.17 now, and not 2.16.

https://issues.apache.org/jira/browse/LOG4J2-3230

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/14/2021 8:08 PM, Stephen Hoffman wrote:
> On 2021-12-14 19:56:24 +0000, Jim said:
>> On 12/14/2021 11:39 AM, Stephen Hoffman wrote:
>>> HPE has indicated that 3PAR and some other products are vulnerable to
>>
>> Seems HPE now reporting that the 3PAR StorServ is not vulnerable.
>>
>> https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00120086en_us
>
> You're looking at the "not vulnerable" list from HPE.
>
> You'll also want to review the "vulnerable" list from HPE, for some
> problematic 3PAR and XP apps.
>
> https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=hpesbgn04215en_us

I saw a list for multiple vendors:

https://www.continuitysoftware.com/blog/centralized-list-of-storage-and-backup-systems-affected-by-zero-day-log4shell-vulnerability-cve-2021-44228

It is a pretty long list!

:-(

Arne

On 12/16/2021 9:46 PM, Arne Vajhøj wrote:
> On 12/14/2021 8:08 PM, Stephen Hoffman wrote:
>> On 2021-12-14 19:56:24 +0000, Jim said:
>>> On 12/14/2021 11:39 AM, Stephen Hoffman wrote:
>>>> HPE has indicated that 3PAR and some other products are vulnerable to
>>>
>>> Seems HPE now reporting that the 3PAR StorServ is not vulnerable.
>>>
>>> https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00120086en_us
>>
>>
>> You're looking at the "not vulnerable" list from HPE.
>>
>> You'll also want to review the "vulnerable" list from HPE, for some
>> problematic 3PAR and XP apps.
>>
>> https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=hpesbgn04215en_us
>
>
> I saw a list for multiple vendors:
>
> https://www.continuitysoftware.com/blog/centralized-list-of-storage-and-backup-systems-affected-by-zero-day-log4shell-vulnerability-cve-2021-44228
>
>
> It is a pretty long list!
>
> :-(

https://www.bleepingcomputer.com/news/security/conti-ransomware-uses-log4j-bug-to-hack-vmware-vcenter-servers

Arne

On 12/16/2021 7:20 PM, Arne Vajhøj wrote:
> On 12/16/2021 5:47 PM, Craig A. Berry wrote:
>> Note that log4j 2.16.0 has now been released to fix vulnerabilities
>> still present in the 2.15.0 released a few days ago, and many of the
>> mitigations published in the last week are now considered inadequate:
>>
>> <https://logging.apache.org/log4j/2.x/security.html>
>
> Yes.
>
> But the new one is not in the same category as the first.
>
> <quote>
> CVE-2021-45046
>
> CVE-2021-45046: Apache Log4j2 Thread Context Message Pattern and Context
> Lookup Pattern vulnerable to a denial of service attack.
>
> Severity: Moderate
>
> Base CVSS Score: 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)
>
> Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
> through 2.15.0
> </quote>

They have now updated the severity to:

CVE-2021-45046 Remote Code Execution
Severity Critical
Base CVSS Score 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
Versions Affected All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2

....

Severity is now Critical

The original severity of this CVE was rated as Moderate; since this CVE
was published security experts found additional exploits against the
Log4j 2.15.0 release, that could lead to information leaks, RCE (remote
code execution) and LCE (local code execution) attacks.

Base CVSS Score changed from 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)
to 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).

The title of this CVE was changed from mentioning Denial of Service
attacks to mentioning Remote Code Execution attacks.

Only Pattern Layouts with a Context Lookup (for example,
$${ctx:loginId}) are vulnerable to this. This page previously
incorrectly mentioned that Thread Context Map pattern (%X, %mdc, or
%MDC) in the layout would also allow this vulnerability.

While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP
lookups to localhost by default, there are ways to bypass this and users
should not rely on this.

> vs
>
> <quote>
> CVE-2021-44228
>
> CVE-2021-44228: Apache Log4j2 JNDI features do not protect against
> attacker controlled LDAP and other JNDI related endpoints.
>
> Severity: Critical
>
> Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
>
> Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
> through 2.14.1
> </quote>

Arne

On 2021-12-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> They have now updated the severity to:
>
> CVE-2021-45046 Remote Code Execution
> Severity Critical
> Base CVSS Score 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
> Versions Affected All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2
>

Perhaps we should just wait for version 2.40.0 to be released, which
will probably be in a couple of weeks at this rate. :-)

For anyone not aware, there is now a third CVE:

https://www.theregister.com/2021/12/19/log4j_new_flaw_cve_2021_45105/

The latest Log4j version is now 2.17.0.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 12/20/2021 2:00 PM, Simon Clubley wrote:
> On 2021-12-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> They have now updated the severity to:
>>
>> CVE-2021-45046 Remote Code Execution
>> Severity Critical
>> Base CVSS Score 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
>> Versions Affected All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2
>>
>
> Perhaps we should just wait for version 2.40.0 to be released, which
> will probably be in a couple of weeks at this rate. :-)
>
> For anyone not aware, there is now a third CVE:
>
> https://www.theregister.com/2021/12/19/log4j_new_flaw_cve_2021_45105/
>
> The latest Log4j version is now 2.17.0.

(Hoff already mentioned that one)

CVE-2021-45105:
Apache Log4j2 does not always protect from infinite recursion in lookup
evaluation
CVE-2021-45105 Denial of Service
Severity High
Base CVSS Score 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Versions Affected All versions from 2.0-beta9 to 2.16.0

Arne

On 2021-12-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> (Hoff already mentioned that one)
>

I missed that. Sorry. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 12/20/2021 2:23 PM, Simon Clubley wrote:
> On 2021-12-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> (Hoff already mentioned that one)
>
> I missed that. Sorry. :-)

And they found yet another vulnerability so now 2.17.1 is out.

Arne

On 2021-12-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 12/20/2021 2:23 PM, Simon Clubley wrote:
>> On 2021-12-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> (Hoff already mentioned that one)
>>
>> I missed that. Sorry. :-)
>
> And they found yet another vulnerability so now 2.17.1 is out.
>

On the plus side, at least the discoveries are getting further apart. :-)

As a gentle reminder to everyone, this is what awaits VMS if the
researchers turn their attention to it. Log4j was in use for years
and only after researchers turned their attention to it, did these
longstanding issues get discovered.

I'm sure that when the vulnerable Log4j versions were introduced,
everyone continued to use it without thinking that they may have
just introduced a vulnerability into their application.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 12/31/2021 5:24 AM, Simon Clubley wrote:
> On 2021-12-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 12/20/2021 2:23 PM, Simon Clubley wrote:
>>> On 2021-12-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> (Hoff already mentioned that one)
>>>
>>> I missed that. Sorry. :-)
>>
>> And they found yet another vulnerability so now 2.17.1 is out.
>>
>
> On the plus side, at least the discoveries are getting further apart. :-)
>
> As a gentle reminder to everyone, this is what awaits VMS if the
> researchers turn their attention to it. Log4j was in use for years
> and only after researchers turned their attention to it, did these
> longstanding issues get discovered.

It is clear that when some software get a lot of attention then
problems tend to be found.

VMS is not quite as attractive as log4j though.

> I'm sure that when the vulnerable Log4j versions were introduced,
> everyone continued to use it without thinking that they may have
> just introduced a vulnerability into their application.

I believe it has been there since 2.0.

2.x API is different from 1.x API, but 2.x comes with a bridge
that supports 1.x API so maybe old applications that were upgraded
from 1.x to 2.x using the bridge is also impacted.

Obviously people were unaware of the problems.

And the vast majority (like 99.99%) have never used the features
that are causing the problems.

Arne

David Turner <dturner@islandco.com> wrote:
> It's better than nothing

If it gives you some peace of mind you can try it in the short term.

BTW, some email environments do allow blocking by country of origin,
e.g., Cisco Email Security Appliances. It's something we have chosen
not to use.

But when waiting for a patch to arrive sometimes you grasp at straws.

My home Linux box has Libre Office, and some report writer functionality
had a dependency on log4j and it did not seem to be possible to remove
log4j without using some kind of --force-remove option, although I
suppose I could have just hidden the executable for that portion of
Libre Office.

I see I have the log4j patch in now as part of a routine patch
application, but I don't believe it was there to begin with so I was
exposed for a few days.

George

> I think a lot of US hosting companies also have blocked suspicious
> Russian traffic and will not allow non-US companies to be hosted.
>
> It has certainly helped us.
>

On 1/6/2022 5:21 PM, George Cornelius wrote:
> My home Linux box has Libre Office, and some report writer functionality
> had a dependency on log4j and it did not seem to be possible to remove
> log4j without using some kind of --force-remove option, although I
> suppose I could have just hidden the executable for that portion of
> Libre Office.
>
> I see I have the log4j patch in now as part of a routine patch
> application, but I don't believe it was there to begin with so I was
> exposed for a few days.

log4j is almost everywhere.

But the attack vector in LO must be rather narrow compared to
all the server applications.

Arne

On Thursday, January 6, 2022 at 6:54:59 PM UTC-5, Arne Vajhøj wrote:
> On 1/6/2022 5:21 PM, George Cornelius wrote:
> > My home Linux box has Libre Office, and some report writer functionality
> > had a dependency on log4j and it did not seem to be possible to remove
> > log4j without using some kind of --force-remove option, although I
> > suppose I could have just hidden the executable for that portion of
> > Libre Office.
> >
> > I see I have the log4j patch in now as part of a routine patch
> > application, but I don't believe it was there to begin with so I was
> > exposed for a few days.
> log4j is almost everywhere.
>
> But the attack vector in LO must be rather narrow compared to
> all the server applications.
>
> Arne
The trouble is that log4j is at such a low level, it is buried in packages that are
buried in other packages that are buried in even more packages. It might take a
while for all of that to be squeezed out.