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.
Also if you use Twitter, then follow GossiTheDog for lots of other links/info.
https://twitter.com/GossiTheDog
I agree,
As an example that back what you're saying, I pasted the ip provided by Jörg in my browser.
Here is the html page returned.
<html>
...
Research Scanning Project
This is a scanner of a research scanning project.
If you want to exclude your IPs from scans, please send an e-mail to exclude@alphastrike.io.
Thank you for your appreciation!
...
</html>
This ip scanner is in Germany and it looks legit, but a better investigation is recommended.
The second host provided looks more suspicious.
blah.c6rip779l9hq8g7hluigcg5131oyyyt8e.interactsh.com resolve to
104.248.51.21 which is hosted on DigitalOcean.
Here is the html output:
<html>
...
Interactsh Server
Interactsh is an open-source solution for out-of-band data extraction. It is a tool designed to detect bugs that cause external interactions. These bugs include, Blind SQLi, Blind CMDi, SSRF, etc.
If you find communications or exchanges with the interactsh.com server in your logs, it is possible that someone has been testing your applications.
You should review the time when these interactions were initiated to identify the person responsible for this testing.
...
</html>
First, it's important to gain visibility and filter the goods from the bads.
The first ip looks legit. The second could be reported to DigitalOcean for investigation. They usually investigate very fast.
You can check for weird network flows patterns. You can also look for that suspicious html file that is crawling on http in clear 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
“Security” people often let perfect be the enemy of good. Sometimes it’s okay. Sometimes not.
Maybe I'm the only one who puts cheap wireless leak sensors near toilets,
drains, and other less-likely sources of water, in addition to the big
alarm system hardwired ones in all the usual places.
Of course, then again, we also have two AC sump pumps and one that is
battery backup, all protected by generator and ATS.
I prefer to know. You, of course, are free to disregard as you see
fit.
... JG
Hi all,
I guess what Jorg is suggesting is that beyond this particular incident, a preventive testing/mitigation methodology would make for a great NANOG2022 presentation/workshop.
Cheers,
Dora
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?
Scan your systems:
-Hank
There's all sorts of statements I might agree with.
However, if I have an easy indicator of a known problem, such as "LDAP
traffic to an unknown server", I might be very tempted to set the IDS
to notify me if it sees the weird thing, and then let the very fast
moron just do its job. That's what it's there for, after all. Right?
I don't care if it misses 9% or 99% or 99.997%. If I can generate some
cheap and easy hits, without finding out about problems the Equifax
way, I don't see the harm in that. Sometimes we do things "just in
case."
... JG
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
This isn’t a new problem.
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 you are not aware of, or could come back with an overlapping class definition based on the order things get loaded.
The same was always true with shared libraries and too-generic function names.
It’s such a blast from the past as I had felt we had moved past many of these interpreted environment or parser things by properly encoding strings with a function.
I’m really amazed at how widespread this is and what enterprise applications have had to get patched due to them embedding this software.
- jared
Alternatively, this incantation solved the problem on my linux server:
rpm -e log4j12 ant-apache-log4j log4j
Owen
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 more light-weight logging library with less magic.
PS: And it is not the first time Log4j ended causing headaches… For those wondering. I remember back in 2017 when everyone was angrily saying they’ll change for something else…
Indeed, it is extremely used.
This new threat seems to behave like a worm. What was the last worm-like virus?
I recall sql slammer or something like that in early 2000.
Was there any other very popular worm between 2003 and now?
Thanks
Jean
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.
TSA?
Oh, wait, never mind. That’s “security theater” and not “security.”
-Andy
This is possibly a weird question, but has anyone set up a known-
vulnerable system? To test especially the second of those scanners?
Alternatively, can anyone here vouch for the tool (i.e., you've done an
A/B test on a site with the vulnerability present and again on the same
system with the vulnerability mitigated, and the tool got it right in
both cases)?
I have plenty of known-INvulnerable systems
The thing is I have a few systems that I would have thought were
vulnerable but the second tool above reports them as not being
vulnerable. Making me slightly doubt the efficacy of the tool. I this
situation, I'd like to know for a fact that it will detect this
vulnerability.
Regards, K.
...
> Log4j – Apache Log4j Security Vulnerabilities
>
> 1. upgrade log4j to 2.15.0 and restart all java apps
> 2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+ only)
> 3. start java with "LOG4J_FORMAT_MSG_NO_LOOKUPS=true" environment variable (v2.10+ only)
> 4. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
>
> There's a lot of scanning going on at the moment, so if you have an exposed java instance running something which includes log4j2, you may already be compromised.
>
> NickAlternatively, this incantation solved the problem on my linux server:
rpm -e log4j12 ant-apache-log4j log4j
There are many software setups that bundle their own log4j.jar without
bothering to go through the OS package manager....
rpm \-qa | fgrep log4j
$ find / -name log4j*jar
....system/log4j/log4j/log4j/1.2.17/log4j-1.2.17.jar
(obviously an old system due to the commands used and version found,
and nor will it get patches available because of vendor...).
Sorta like playing whack-a-mole with jquery.js (another package with
lots of security history that seems to be copied _everywhere_ without
registring it with the OS package manager).
So, the exercise becomes _finding_ the software that uses it, and then
doing the configs that defang JNDI everywhere you find it.
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
YMMV… Find didn’t find anything named log4j\*jar after I did my rpm -e.
Owen