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?
Let us know if there is better advice to monitor access to the IMDS.
Intrusion Detection In-Depth - SANS Doha March 2022
Dec 23rd 2021
|Thread locked Subscribe||
Dec 23rd 2021
1 month ago