> On Dec 14, 2021, at 14:43 , Nick Hilliard wrote:
>
> The log4j people have updated their security advisory to say that these two
> mitigation measures are not sufficient to protect against the recent
> vulnerability:
>
>> 2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+
The log4j people have updated their security advisory to say that these
two mitigation measures are not sufficient to protect against the recent
vulnerability:
2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+ only)
3. start java with "LOG4J_FORMAT_MSG_NO_LOOKUPS=true"
Thanks… That did find some additional packages hiding this scourge (about a
dozen or so packages,
around 100 packages removed after the dependency chains were resolved).
> On Dec 14, 2021, at 09:30 , Tyler Conrad wrote:
>
> Another handy one to find where it's hiding, since it can be bundled
> On Dec 14, 2021, at 06:54 , Doug McIntyre wrote:
>
> On Mon, Dec 13, 2021 at 11:38:04AM -0800, Owen DeLong via NANOG wrote:
>>> On Dec 11, 2021, at 04:11 , Nick Hilliard wrote:
> ...
>>> https://logging.apache.org/log4j/2.x/security.html
>>>
>>> 1. upgrade log4j to 2.15.0 and restart all
Another handy one to find where it's hiding, since it can be bundled inside
other JARs:
find / -name *.jar | xargs strings -f | grep -i log4j
On Tue, Dec 14, 2021 at 6:57 AM Doug McIntyre wrote:
> On Mon, Dec 13, 2021 at 11:38:04AM -0800, Owen DeLong via NANOG wrote:
> > > On Dec 11, 2021, at
On Mon, Dec 13, 2021 at 11:38:04AM -0800, Owen DeLong via NANOG wrote:
> > On Dec 11, 2021, at 04:11 , Nick Hilliard wrote:
...
> > https://logging.apache.org/log4j/2.x/security.html
> >
> > 1. upgrade log4j to 2.15.0 and restart all java apps
> > 2. start java with "-D
On Mon, 2021-12-13 at 17:07 +0200, Hank Nussbacher wrote:
> Scan your systems:
> https://github.com/logpresso/CVE-2021-44228-Scanner
> https://github.com/fullhunt/log4j-scan
This is possibly a weird question, but has anyone set up a known-
vulnerable system? To test especially the second of those
On 13. Dec 2021, at 20:32, Jared Mauch wrote:
>
> This is an great modern example showing how deeply embedded things could be,
> and they get worse with each of these nesting technologies as well, it may be
> embedded in a docker or VM image, or the class could be in some other JAR or
> zip
> On Dec 13, 2021, at 3:57 PM, Karl Auer wrote:
>
> On Mon, 2021-12-13 at 08:01 -0600, Mike Hammett wrote:
>> "Security" people often let perfect be the enemy of good. Sometimes
>> it's okay. Sometimes not.
>
> Can you offer an example of where it's okay?
>
> I'm not a "security" person.
On Mon, 2021-12-13 at 08:01 -0600, Mike Hammett wrote:
> "Security" people often let perfect be the enemy of good. Sometimes
> it's okay. Sometimes not.
Can you offer an example of where it's okay?
I'm not a "security" person. Also not sure what the double quotes mean
:-)
Regards, K.
--
Hebert
Sent: December 13, 2021 3:01 PM
To: nanog@nanog.org
Subject: Re: Log4j mitigation
Well,
In my experience, it is a really widely used library. It has been pretty
much the de-facto standard for logging for a long while.
IMHO
So anything Java (and exposed obviously) need
Well,
In my experience, it is a really widely used library. It has been
pretty much the de-facto standard for logging for a long while.
IMHO
So anything Java (and exposed obviously) need a review...
Best Practices
As a standard we always tent to push our customers to
> On Dec 11, 2021, at 04:11 , Nick Hilliard wrote:
>
> Andy Ringsmuth wrote on 11/12/2021 03:54:
>> The intricacies of Java are over my head, but I’ve been reading about this
>> Log4j issue that sounds pretty bad.
>> What do we know about this? What, if anything, can a network operator do to
> On Dec 13, 2021, at 2:24 PM, Owen DeLong wrote:
>
> The bigger problem seems to be the ever growing list of products you may be
> using which depend on it potentially without your knowledge.
This isn’t a new problem.
This is an great modern example showing how deeply embedded things
The bigger problem seems to be the ever growing list of products you may be
using which depend on it potentially without your knowledge.
Owen
> On Dec 11, 2021, at 03:41 , Jared Mauch wrote:
>
> This is largely a patching exercise for people that use the software. If you
> use it, please
On Mon, Dec 13, 2021 at 03:50:11PM +0100, J??rg Kost wrote:
> But in a world where the attacker can leak out a whole 16-bit integer,
> monitoring that 0.003% for two-port states may be irrelevant.
> Not saying you shall not, but you will miss 99.997%. Agree?
There's all sorts of statements I
On 13/12/2021 15:28, bofh139 wrote:
Now we have the long journey from Java, Ldap, DNS, Birds and Coffee Cups
behind us. Does anyone else have any advice on prevention?
Scan your systems:
https://github.com/logpresso/CVE-2021-44228-Scanner
https://github.com/fullhunt/log4j-scan
-Hank
But in a world where the attacker can leak out a whole 16-bit integer,
monitoring that 0.003% for two-port states may be irrelevant.
Not saying you shall not, but you will miss 99.997%. Agree?
On 13 Dec 2021, at 15:22, Joe Greco wrote:
> On Mon, Dec 13, 2021 at 01:49:07PM +0100, J??rg Kost
arly become easy
> to identify.
>
> I agree with Karl that perfection is enemy of good.
>
> Jean
>
> -Original Message-
> From: NANOG On Behalf Of Karl
> Auer
> Sent: December 13, 2021 7:55 AM
> To: NANOG List
> Subject: Re: Log4j mitigation
>
>
On Mon, Dec 13, 2021 at 01:49:07PM +0100, J??rg Kost wrote:
> I understand what you want to say, but I disagree in this point. When
> you have a cup full of water and someone remotely can drill holes into
> the out shell, just checking the bottom for leaks won't help. You may
> want a new mug
"NANOG List"
Sent: Monday, December 13, 2021 6:54:30 AM
Subject: Re: Log4j mitigation
On Mon, 2021-12-13 at 06:35 -0600, Joe Greco wrote:
> Just because there are other sources of fatalities, doesn't mean you
> can't check for the quick obvious stuff.
Indeed.
One check, ev
text on your gears.
At ISP level, visibility is a must and patterns will clearly become easy to
identify.
I agree with Karl that perfection is enemy of good.
Jean
-Original Message-
From: NANOG On Behalf Of Karl Auer
Sent: December 13, 2021 7:55 AM
To: NANOG List
Subject: Re: Log4j
>Now we have the long journey from Java, Ldap, DNS, Birds and Coffee Cups
behind us. Does anyone else have any advice on prevention?
There is a good Mega Thread over on /r/BlueTeamSec.
https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
Also if you use Twitter, then
On Mon, 2021-12-13 at 06:35 -0600, Joe Greco wrote:
> Just because there are other sources of fatalities, doesn't mean you
> can't check for the quick obvious stuff.
Indeed.
One check, even an inadequate one, is better than no checks at all. And
over time you can add more checks or improve the
I understand what you want to say, but I disagree in this point. When
you have a cup full of water and someone remotely can drill holes into
the out shell, just checking the bottom for leaks won't help. You may
want a new mug instead. :-) The initial posting was about looking at the
bottom
On Mon, Dec 13, 2021 at 01:12:25PM +0100, J??rg Kost wrote:
> Yes, but it won't change the outcome. We shall run with assuming breach
> paradigm. In this scenario, it might be useless looking around for port
> 389 only; it can give you a wrong assumption.
That's like arguing that it isn't worth
Yes, but it won't change the outcome. We shall run with assuming breach
paradigm. In this scenario, it might be useless looking around for port
389 only; it can give you a wrong assumption.
When a vulnerable system has a reachable path to the Internet and can
open a reverse shell alone from
On Mon, Dec 13, 2021 at 12:39:58PM +0100, J??rg Kost wrote:
> You can't see it.
I think you meant "you can't reliably see it". This doesn't mean
that it isn't worth looking for obvious cases where you CAN see
it.
... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI -
:40 AM
To: Jean St-Laurent
Cc: Saku Ytti ; nanog@nanog.org
Subject: Re: Log4j mitigation
You can't see it. The attack vector can hide in HTTP GETs, Posts (SSL), in
Headers, in anything related to where a Java process does logging with Log4j;
it's innumerable. It might even evaluate from a URI
The Base64 part tries to open a shell on the target host, you can decode
yourself.
On 13 Dec 2021, at 12:39, Jörg Kost wrote:
You can't see it. The attack vector can hide in HTTP GETs, Posts
(SSL), in Headers, in anything related to where a Java process does
logging with Log4j; it's
You can't see it. The attack vector can hide in HTTP GETs, Posts (SSL),
in Headers, in anything related to where a Java process does logging
with Log4j; it's innumerable. It might even evaluate from a URI itself;
it won't use a fixed port. It's not wormy right now, but maybe it will
soon.
We
To: Jean St-Laurent
Cc: Jörg Kost ; nanog@nanog.org
Subject: Re: Log4j mitigation
On Mon, 13 Dec 2021 at 13:31, Jean St-Laurent wrote:
> It's possible to see it live crawling in your network. Why let something
> harmful continue to crawl and spread?
My apologies, I missed this par
On Mon, 13 Dec 2021 at 13:31, Jean St-Laurent wrote:
> It's possible to see it live crawling in your network. Why let something
> harmful continue to crawl and spread?
My apologies, I missed this part. How?
--
++ytti
6:26 AM
To: Jean St-Laurent
Cc: Jörg Kost ; nanog@nanog.org
Subject: Re: Log4j mitigation
I don't think the implication made that solution space contains only Snake Oil
and panic. There is also an alternative to update the log4j package, which
deserves review before deciding between snake oil
right, but it's still a good place to start looking.
>
> What do you recommend? Panic?
>
> It won't help you.
>
> Jean
>
> -Original Message-
> From: Jörg Kost
> Sent: December 13, 2021 6:01 AM
> To: Jean St-Laurent
> Cc: Nick Hilliard ; Andy Ringsmuth
On 13 Dec 2021, at 12:11, Jean St-Laurent wrote:
> You are right, but it's still a good place to start looking.
It is not. It will give you false assumptions.
>
> What do you recommend? Panic?
>
Yes. Out in public for four days, you better should assume breach by now.
You are right, but it's still a good place to start looking.
What do you recommend? Panic?
It won't help you.
Jean
-Original Message-
From: Jörg Kost
Sent: December 13, 2021 6:01 AM
To: Jean St-Laurent
Cc: Nick Hilliard ; Andy Ringsmuth ;
nanog@nanog.org
Subject: Re: Log4j
It's not true.
It can pull from other ports, URLs, make DNS calls, and seems to
evaluate even from environment variables.
It's a "virtual machine".
On 13 Dec 2021, at 11:54, Jean St-Laurent via NANOG wrote:
Well if you look to the right you won't see it, but if you look to the
left you will
Hilliard
Sent: December 11, 2021 7:12 AM
To: Andy Ringsmuth
Cc: nanog@nanog.org
Subject: Re: Log4j mitigation
Andy Ringsmuth wrote on 11/12/2021 03:54:
> The intricacies of Java are over my head, but I’ve been reading about this
> Log4j issue that sounds pretty bad.
>
> What do w
Am 11.12.2021 um 04:54 schrieb Andy Ringsmuth :
>
> The intricacies of Java are over my head, but I’ve been reading about this
> Log4j issue that sounds pretty bad.
>
> What do we know about this? What, if anything, can a network operator do to
> help mitigate this? Or even an end user?
Andy Ringsmuth wrote on 11/12/2021 03:54:
The intricacies of Java are over my head, but I’ve been reading about this
Log4j issue that sounds pretty bad.
What do we know about this? What, if anything, can a network operator do to
help mitigate this? Or even an end user?
The payload can be
This is largely a patching exercise for people that use the software. If you
use it, please patch.
Sent via RFC1925 complaint device
> On Dec 10, 2021, at 10:59 PM, Andy Ringsmuth wrote:
>
> The intricacies of Java are over my head, but I’ve been reading about this
> Log4j issue that
42 matches
Mail list logo
