Thanks to Mick Douglas for contributing these notes on defending against log4shell exploits targeting cloud Internal Meta Data Services (IMDS)

A new twist on using the Log4j vulnerability was discovered that could allow attackers access to the IMDS. This allows them to gather detailed and current information about your cloud infrastructure. Typically, attackers cannot easily do this because cloud providers have protections that prevent this type of access. With Log4j, if your system is vulnerable, attackers can make requests appear to come from trusted infrastructure from within your cloud.

Before we get into defenses, it's imperative that you understand patching is your path of least resistance. Please patch if at all possible. If you cannot patch, I personally suggest the IMMA model. Here's how IMMA would work in this instance.

Isolate:

• Setup a WAF for all internet-facing systems. There are detects for this the Log4j attack in all main providers.
• If you can, disable the IMDS web access. Typically this is a bad idea since it breaks almost all automation, but if you don't need it, turn it off for now.

Minimize:

• Prevent attacker callbacks by doing strong egress controls. Only allow protocols out that are needed.
• Review network trust boundaries. Consider reviewing all access into your systems, pay careful attention to third parties which have special network linkages. Don't allow your MSSP or cloud VAR to be the source of your attack!
• Limit access for tokens used by infrastructure. At a minimum, review what your defaults are.

Monitor:

• Review logs on your applications. You are looking for JNDI requests. These are exceedingly rare.
• Look for unplanned configuration changes.
• Look for network enumeration. Only auditors and attackers ask to see network setups. Everything else knows what to talk to!
• Look for token use from outside your cloud providers' ASN. Tokens should only be coming from the provider that issues them. The only exception will be admins who use tokens from CLI shells. Those you can make an exception list for.
• Detect new and unexpected connections. Cloud systems have a very predictable interaction mapping. When this changes, you should be able to see it.

Active Defense:

• Token lifetimes: If you create tokens with non-standard lifetimes, when someone creates a new token of the maximum lifetime (typically 6 hours) that's highly noticeable.
• Honey tokens: create fake tokens and see if anyone tries to use them anywhere.
• Setup honey environment variables: IDMS supports almost any data. Why not give attackers something juicy and see if they try to use it anywhere? One of my favorite use cases for this is "AutomationAdminAccessToken=068f073e79fd3b69be0b0a1338537aff" See if they try using it!

Mick Douglas,
Principle SANS Instructor
IANS Faculty
Founder and Managing Partner, InfoSec Innovations