Are you running an application in a cloud environment like Amazon's EC2? Cloud providers usually offer a nifty way to manage credentials: Internal Meta Data Services (IMDS). For AWS, the IMDS listens on 169.254.169.254. 169.254/16 being link-local only,  only code running on the host itself can reach it, and your code can use this service to retrieve credentials. Or, well, any code running on the host can. 

As Mick Douglas pointed out in his tweet here:

Kat Traxler's blog post, referred to by Mick, has more details.

In Amazon's case, two versions of the IMDS are offered. Exploitation is trivial for IMDSv1. All it takes is an SSRF vulnerability, and as JNDI is all about sending requests to arbitrary hosts, this is covered. Amazon hardened its IMDS implementation in version 2 (using a PUT request to retrieve an access token first). But with log4j, you got arbitrary code execution, so sending a PUT and the following GET with the proper authentication header is pretty straightforward.

This issue isn't just a log4j issue. It is common to all remote code execution vulnerabilities in cloud environments (or again to some SSRF issues). 

Can you do something other than patching all your log4j instances?

• You may disable the IMDS service if not needed (careful!)
• Verify all your cloud permissions (right... patching is likely easier)
• most importantly: rotate credentials on systems you suspect are compromised (= all unpatched systems at this point)

Let us know if there is better advice to monitor access to the IMDS.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|