In this lesson,
we're going to discuss how a penetration tester
can attack the metadata service.
The metadata service is used to provide data
about an organization's instances so that it can configure
or manage their running instances in the cloud.
The instance metadata is then divided into categories,
such as host name, events and security groups.
When we talk about metadata, remember that it's data
that provides information about other data.
For example, if I had metadata about your last phone call
that you made on your smartphone,
I would not know what you said on that call,
but I would know the phone number your called,
how long you talked for, whether you called them
or they called you and things like that.
This is data about the phone call itself,
but not the contents of that actual phone call.
Well, the metadata service is used in AWS
to provide data about the instances
that are being run in an organization's AWS cloud account.
While this type of data about data may seem harmless,
there have been some big breaches
that are tied back to attacks against the metadata service
as the initial attack vector.
For example, back in July of 2019,
Capital One announced that they had a weakness
in the Amazon Web Services instance metadata service
that was the source of the data breach
on their cloud architecture.
This wasn't the first time
that the instance metadata service
was found to be lacking in security either,
because security researchers have been presenting reports
and presentations on this weakness since as early as 2014
when researcher Andres Riancho gave a talk entitled,
"Pivoting in Amazon Clouds".
So how can the metadata service be exploited?
Well, it all starts with an SSRF
or a server-side request forgery.
Remember, a server-side request forgery
is a type of attack that takes advantage
of the trust relationship between the server
and the other resources that it can access.
A server-side request forgery vulnerability
occurs whenever a web application
is fetching a remote resource
without first validating the user-supplied URL.
This allows an attacker to coerce the application
to send a crafted request to an unexpected destination,
even if it's protected by a firewall, VPN
or other type of network access control list.
Now, these server-side request forgeries
are used to exploit vulnerable applications,
communicate with the metadata service, extract credentials
and pivot into an organization's cloud account.
To conduct this attack, a penetration tester first needs
to identify the application
or cloud-based service that is vulnerable
to a server-side request forgery vulnerability.
For example, let's consider the sample application
that uses the following code written in JavaScript,
public async IActionResult Get (string target),
var client = new HttpClient,
var request = client.GetAsync (target),
var json = await,
result.Content.ReadAsStringAsync,
return JsonConvert.DeserializeObject(json).
All right, this code essentially allows an API endpoint
to accept an untrusted target parameter from the request.
Then it performs a get request to that target
and returns a response back to the client.
This essentially is acting as a proxy service.
This code is actually written in JavaScript.
Now, this is going to accept a request
from a user or a service on the front end
and then it's going to turn around
and proxy that over to a backend service
to request the information from an API
located on that same domain.
For example, I might have something like,
https://diontraining.com/proxy?target=http://
diontraining.com/api/scientists
and this is going to return a list
of some of the great scientists
that are stored in my database
to this front end application in JSON format.
So I might get something back like,
"id: "1234", "firstname": "Charles", "lastname": "Darwin",
"id: "5678", "firstname": "Albert", "lastname": "Einstein",
"id: "4321", "firstname": "Dimitri",
"lastname": "Mendeleev".
You get the idea here.
Now again, this look fairly harmless,
except that we have security researchers
and penetration testers who were able to quickly figure out
that you can change the target that's being specified
and then attack the metadata service instead
of proxying this connection to that backend database
that we were asking it to do.
For example, if you used
https://diontraining.com/proxy?target=http:
//169.254.169.254/latest/meta-data/iam/
security-credentials/Admin-WAF-Role/,
you're actually going to cause a server-side request forgery
to the instance metadata service and receive a JSON response
from that new endpoint, in this case, 169.254.169.254.
Now this comes back with something that looks like this.
"Code": "Success",
"LastUpdated":, a date and time.
"Type": "AWS-HMAC",
"AccessKeyId":, and the access key ID.
"SecretAccessKey", and the secret access key,
the token, the expiration.
You get the idea.
This JSON response is going to provide us
with the temporary credentials to the service account
that's assigned to that particular resource
in the instance metadata service.
These keys could then be used to communicate directly
with the organization's could account.
Now, there's a lot more to this type of an attack,
but for the exam, you just need to remember
that the metadata service attack
is a form of server-side request forgery attack
that focuses on taking metadata about the instances
and using it to get the value of the instances
or containers and their associated credentials and keys.
As the different vulnerabilities and exploits
are always rapidly changing all the time,
especially in the world of cloud computing,
you need to continue to stay up to date
with the latest exploits and techniques
as you enter the world of penetration testing.
For the exam though, they are not going to ask you
about specific exploits
like Puma Scan's SCC0129 server-side request forgery tool
that I used here,
but they are going to you about the concepts
being exploited in the metadata service attack
as I briefly described in this lesson.