Paranoia

7f000001 sweet a9fea9fe // hex.

The recent events should remind us, that IT professionals are not invincible and are targeted as well. Comfort might numb sensibility and awareness. Active counter measures should be deployed and reevaluated. Opsec should not be a one time project, but must be seen as a continues multistep process.

This article tries to enlighten a special part of operational security: The local setup. ¹

So without further a due:

“The first rule of OPSEC club is tell everyone about OPSEC!” TheGrugq 2016

Overview

One of the mean aspects of opsec is the sheer scale of things to be aware of. The following diagram is by no means holistic nor based on academic papers, but represents one strategy to categorize the topics.

This article focus on one specific aspects of the traffic redirector and the local setup of the operator. If you are interested in other parts of the puzzle:

• BlackHillSecurity recently released OPEC Fundamentals1. There Michael describes some problems that red teams faces and some potential solutions.

• Outflanks RedElk is a good approach in tracking and monitoring your Redteam infrastructure since ‘Just as blue teams need to protect their infra, red teams need to do just so. ‘

• Malcoms Advises Advises for red teams in general

• SpecterOps Ghostwriter for organizational management and much more related to assessments.

• MD Sec insights how to automate the setup via terraform and Ansible. Bonus: Validate everything using ‘molecule’, ‘testinfra’ and ‘inspec’. Additional resources on terraform infrastructure: ired.team’s Article.

  Furthermore, Silentbreak’s and praetorian’s article might also help you based on an architectural overview

Metadata API

For manual red team/pentesting traffic is always tunneled - either through SOCKS, OpenVPN, Wireguard or additional tools for recon or vulnerability testing of web apps/burp.

If these tools are deployed in the cloud of large cloud providers (T1583), then visiting a website might expose or risk your operation/infrastructure if the Metadata API is reachable from your VM.

Potential Impact:

• Of course if credentials/security tokens can be accessed, then the infrastructure could potentially be compromised as demonstrated by various articles ^{2 3}

• Additionally Metadata, such as tags, hostname and user might reveal your identity if you use them as aliases on github.com, twitter.com or even your personal blog.

• Last but not least public_keys. As described in this wonderful blogpost the public_key is enough to enumerate servers and the infrastructure. This is especially bad, since most of the infrastructure is instrumented and configured automatically.

‘‘Vulnerability’’ Check

You can simply check if you are vulnerable by browsing in your VM to one of the following URLs or use curl

Table of typical cloud providers and its metadata api from Prinzhorn:

Example:

On my qube with wireguard proxy terminating on a Digital Ocean Droplet this is the output:

Well damn … but you need RCE on the machine, so you’ll need a 0day browser exploit right ? Right ?!?

Proof-of-Concept

Well, no. A DNS-rebinding attack would work fine to gather the data from most⁴ of the cloud providers.

A DNS-rebinding attack is necessary, since your browser protects you. A malicious website cannot access content from other HTTP services without specifying additional Headers (thanks to CORS restriction).

Through a combination of both DNS Rebinding servers of ncc’s Singularity and saelo’s it is possible to exfiltrate the metadata successfully after a few seconds browsing only an attacker controlled ‘‘blog’’. Furthermore, Singularity even provides a neat little metadata script.

Details:

• Victim links on link
• Browser resolves the URL
• DNS server response with an external IP, where the content is served
• Browser loads content
• The JavaScript tries different methods to force the browser to lookup the domain once again
• Browser resolves domain again
• DNS Server response with different IP: 169.254.169.264
• JavaScript tries to access public-key data through resolved domain or exploit local services
• Access content, since the browser accepts requests/content to the same domain.
• JavaScript exfiltrate the data to other server

Now as the final step the data can be evaluated.

• Are credentials leaked ?
• Are usernames or tags help in identifying the organization or user ?
• Test public key against cloud provider to identify more assets.
• Different IP to pwn unprotected local services

Summary

Yes in theory this vector is possible and after some more preparation a stable, reliable exploit can be created to exfiltrate or even attack local services. In the next article a few more options will also be described.

• Disable the MetadataAPI on your cloud instances
• To protect from DNS Rebinding: take a look at the slides from NCC (TLS, Authentication and Host header verification)
• Monitor DNS traffic (it’s always DNS) :D