Carnal0wnage Blog

Monday, January 14, 2019

Kubernetes: List of ports

Other Kubernetes ports

What are some of the visible ports used in Kubernetes?

44134/tcp - Helmtiller, weave, calico
10250/tcp - kubelet (kublet exploit)

No authN, completely open
/pods
/runningpods
/containerLogs

10255/tcp - kublet port (read-only)

/stats
/metrics
/pods

4194/tcp - cAdvisor
2379/tcp - etcd (see it on other ports though)

Etcd holds all the configs
Config storage

30000 - dashboard
443/6443 - api

Friday, January 11, 2019

Kubernetes: Kubernetes Dashboard

Tesla was famously hacked for leaving this open and it's pretty rare to find it exposed externally now but useful to know what it is and what you can do with it.

Usually found on port 30000

kube-hunter finding for it:

Vulnerabilities
+-----------------------+---------------+----------------------+----------------------+------------------+
| LOCATION | CATEGORY | VULNERABILITY | DESCRIPTION | EVIDENCE |
+-----------------------+---------------+----------------------+----------------------+------------------+
| 1.2.3.4:30000 | Remote Code | Dashboard Exposed | All oprations on the | nodes: pach-okta |
| | Execution | | cluster are exposed | |
+-----------------------+---------------+----------------------+----------------------+------------------+

Why do you care? It has access to all pods and secrets within the cluster. So rather than using command line tools to get secrets or run code you can just do it in a web browser.

Screenshots of what it looks like:

viewing secrets

utilization

logs

shells

Kubernetes: Kubelet API containerLogs endpoint

You'll need the namespace, pod name and container name.

Thus given the below runningpods output:

{"metadata":{"name":"monitoring-influxdb-grafana-v4-6679c46745-zhvjw","namespace":"kube-system","uid":"0d22cdad-06e5-11e9-a7f3-6ac885fbc092","creationTimestamp":null},"spec":{"containers":[{"name":"grafana","image":"sha256:8cb3de219af7bdf0b3ae66439aecccf94cebabb230171fa4b24d66d4a786f4f7","resources":{}},{"name":"influxdb","image":"sha256:577260d221dbb1be2d83447402d0d7c5e15501a89b0e2cc1961f0b24ed56c77c","resources":{}}]},

turns into:

https://1.2.3.4:10250/containerLogs/kube-system/monitoring-influxdb-grafana-v4-6679c46745-zhvjw/grafana

and

https://1.2.3.4:10250/containerLogs/kube-system/monitoring-influxdb-grafana-v4-6679c46745-zhvjw/influxdb

Monday, January 7, 2019

Kubernetes: Master Post

I have a few Kubernetes posts queued up and will make this the master post to index and give references for the topic. If i'm missing blog posts or useful resources ping me here or twitter.

Talks you should watch if you are interested in Kubernetes:

Hacking and Hardening Kubernetes Clusters by Example [I] - Brad Geesaman

https://www.youtube.com/watch?v=vTgQLzeBfRU
https://github.com/bgeesaman/
https://github.com/bgeesaman/hhkbe [demos for the talk above]
https://schd.ws/hosted_files/kccncna17/d8/Hacking%20and%20Hardening%20Kubernetes%20By%20Example%20v2.pdf [slide deck]

Perfect Storm Taking the Helm of Kubernetes Ian Coldwater

https://www.youtube.com/watch?v=1k-GIDXgfLw

A Hacker's Guide to Kubernetes and the Cloud - Rory McCune

https://www.youtube.com/watch?v=dxKpCO2dAy8

Shipping in Pirate-Infested Waters: Practical Attack and Defense in Kubernetes

Sunday, January 6, 2019

Kubernetes: cAdvisor

"cAdvisor (Container Advisor) provides container users an understanding of the resource usage and performance characteristics of their running containers. It is a running daemon that collects, aggregates, processes, and exports information about running containers."

runs on port 4194

Links:
https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/
https://raesene.github.io/blog/2016/10/14/Kubernetes-Attack-Surface-cAdvisor/

What do you get?

information disclosure about metrics of the containers.

Example request to hit the API and dump data:

http://1.2.3.4:4194/api/v2.0/spec?recursive=true

Screenshots

Kubernetes: open etcd

Quick post on Kubernetes and open etcd (port 2379)

"etcd is a distributed key-value store. In fact, etcd is the primary datastore of Kubernetes; storing and replicating all Kubernetes cluster state. As a critical component of a Kubernetes cluster having a reliable automated approach to its configuration and management is imperative."

-from: https://coreos.com/blog/introducing-the-etcd-operator.html

What this means in english is that etcd stores the current state of the Kubernetes cluster usually including the kubernetes tokens and passwords. If you check out the following references you can get a sense for the pain level that could potentially be involved. At minimum you can get network info or running pods and at best credentials.

refs:
https://techbeacon.com/hackers-guide-kubernetes-security
https://elweb.co/the-security-footgun-in-etcd/
https://raesene.github.io/blog/2017/05/01/Kubernetes-Security-etcd/

the second link talks extensively around types of info the found when they hit all the shodan endpoints for 2379 and did some analysis on the results.

If you manage to find open etcd the easiest way to check for creds is to just do a curl request for:

GET http://ip_address:2379/v2/keys/?recursive=true

Example Loot -

Usually it's boring stuff like this:

But occasionally you'll get more interesting things like:

or more fun things like kublet tokens:

Kubernetes: kube-hunter.py etcd

I mentioned in the master post one a few auditing tools that exist. Kube-Hunter is one that is pretty ok. You can use this to quickly scan for multiple kubernetes issues.

Example run:
$ ./kube-hunter.py
Choose one of the options below:
1. Remote scanning (scans one or more specific IPs or DNS names)
2. Subnet scanning (scans subnets on all local network interfaces)
3. IP range scanning (scans a given IP range)
Your choice: 1
Remotes (separated by a ','): 1.2.3.4
~ Started
~ Discovering Open Kubernetes Services...
|
| Etcd:
| type: open service
| service: Etcd
|_ host: 1.2.3.4:2379
|
| Etcd Remote version disclosure:
| type: vulnerability
| host: 1.2.3.4:2379
| description:
| Remote version disclosure might give an
|_ attacker a valuable data to attack a cluster
|
| Etcd is accessible using insecure connection (HTTP):
| type: vulnerability
| host: 1.2.3.4:2379
| description:
| Etcd is accessible using HTTP (without
| authorization and authentication), it would allow a
| potential attacker to
| gain access to
|_ the etcd
|
| Etcd Remote Read Access Event:
| type: vulnerability
| host: 1.2.3.4:2379
| description:
| Remote read access might expose to an
|_ attacker cluster's possible exploits, secrets and more.

----------

Nodes
+-------------+----------------+
| TYPE | LOCATION |
+-------------+----------------+
| Node/Master | 1.2.3.4 |
+-------------+----------------+

Detected Services
+---------+---------------------+----------------------+
| SERVICE | LOCATION | DESCRIPTION |
+---------+---------------------+----------------------+
| Etcd | 1.2.3.4:2379 | Etcd is a DB that |
| | | stores cluster's |
| | | data, it contains |
| | | configuration and |
| | | current state |
| | | information, and |
| | | might contain |
| | | secrets |
+---------+---------------------+----------------------+

Vulnerabilities
+--------------+------------------+----------------------+---------------------+--------------------------+
| LOCATION | CATEGORY | VULNERABILITY | DESCRIPTION | EVIDENCE |
+--------------+------------------+----------------------+---------------------+--------------------------+
| 1.2.3.4:2379 | Unauthenticated | Etcd is accessible | Etcd is accessible | {"etcdserver":"3.3.9 |
| | Access | using insecure | using HTTP (without | ","etcdcluster":"3.3 |
| | | connection (HTTP) | authorization and | ... |
| | | | authentication), it | |
| | | | would allow a | |
| | | | potential attacker | |
| | | | to | |
| | | | gain access to | |
| | | | the etcd | |
+---------------------+----------------------+----------------------+----------------------+--------------+
| 1.2.3.4:2379 | Information | Etcd Remote version | Remote version | {"etcdserver":"3.3.9 |
| | Disclosure | disclosure | disclosure might | ","etcdcluster":"3.3 |
| | | | give an attacker a | ... |
| | | | valuable data to | |
| | | | attack a cluster | |
+---------------------+----------------------+----------------------+----------------------+--------------+
| 1.2.3.4:2379 | Access Risk | Etcd Remote Read | Remote read access | {"action":"get","nod |
| | | Access Event | might expose to an | e":{"dir":true,"node |
| | | | attacker cluster's | ... |
| | | | possible exploits, | |
| | | | secrets and more. | |
+--------------+------------------+----------------------+---------------------+--------------------------+

Wednesday, January 2, 2019

I found a GCP service account token...now what?

Google Cloud Platform (GCP) is rapidly growing in popularity and i haven't seen too many posts on f**king it up so I'm going to do at least one :-)

Google has several ways to do authentication but most likely what you are going to come across shoved into code somewhere or in a dotfiles is a service account json file.

It's going to look similar to this:

These service account files are similar to AWS tokens in that it can be difficult to determine what they have access to if you don't already have console and/or IAM access. However with a little bit of scripting we can brute force at least some of the token's functionality pretty quickly. The issue being service accounts for something like GCP compute looks the same as one you made to manage your calendar or one of the 100's of other Google services.

You'll need to install the gcloud tools for you OS. Info here: https://cloud.google.com/sdk/

Once you have the gcloud suite of tools installed you can auth with the json file with the following command:

gcloud auth activate-service-account --key-file=KEY_FILE

If they key is invalid you'll see something like the below:

gcloud auth activate-service-account --key-file=21.json
ERROR: (gcloud.auth.activate-service-account) There was a problem refreshing your current auth tokens: invalid_grant: Not a valid email or user ID.

Otherwise it will look similar to below:

gcloud auth activate-service-account --key-file=/Users/CG/Documents/pentest/gcp-weirdaal/gcp.json
Activated service account credentials for: [python@removed.iam.gserviceaccount.com]

you can validate it worked by issuing gcloud auth list command:

gcloud auth list
Credentialed Accounts
ACTIVE ACCOUNT

* python@removed.iam.gserviceaccount.com

I put together a shell script that runs though a bunch of command to enumerate information. They only you info need to provide is the project name. This can be found in the json file in the project_id field or by issuing the gcloud project list command. Sometimes there are multiple projects associated with an account and you'd need to run the shell script with for each project.

The first time you run these api calls you might need to pass a "Y" to the cli to enable it. you can get around this manual shenanigans by doing a:

yes | ./gcp_enum.sh

This will answer Yes for you each time :-)

The script is here: https://gist.github.com/carnal0wnage/757d19520fcd9764b24ebd1d89481541

NCC Group also has two tools you could check out:

https://github.com/nccgroup/G-Scout

and

https://github.com/nccgroup/ScoutSuite

enjoy

CG

Thursday, November 29, 2018

AWS EC2 instance userData

In the effort to get me blogging again I'll be doing a few short posts to get the juices flowing (hopefully).

Today I learned about the userData instance attribute for AWS EC2.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

In general I thought metadata was only things you can hit from WITHIN the instance via the metadata url: http://169.254.169.254/latest/meta-data/

However, if you read the link above there is an option to add metadata at boot time.

You can also use instance metadata to access user data that you specified when launching your instance. For example, you can specify parameters for configuring your instance, or attach a simple script.

That's interesting right?!?! so if you have some AWS creds the easiest way to check for this (after you enumerate instance IDs) is with the aws cli.

$ aws ec2 describe-instance-attribute --attribute userData --instance-id i-0XXXXXXXX

An error occurred (InvalidInstanceID.NotFound) when calling the DescribeInstanceAttribute operation: The instance ID 'i-0XXXXXXXX' does not exist

ah crap, you need the region...

$ aws ec2 describe-instance-attribute --attribute userData --instance-id i-0XXXXXXXX --region us-west-1
{
"InstanceId": "i-0XXXXXXXX",
"UserData": {
"Value": "bm90IHRvZGF5IElTSVMgOi0p"}

anyway that can get tedious especially if the org has a ton of things running. This is precisely the reason @cktricky and I built weirdAAL. Surely no one would be sticking creds into things at boot time via shell scripts :-)

The module loops trough all the regions and any instances it finds and queries for the userData attribute. Hurray for automation.

That module is in the current version of weirdAAL. Enjoy.

-CG

Thursday, February 8, 2018

Dark Side Ops I & 2 Review

Dark Side Ops I
https://silentbreaksecurity.com/training/dark-side-ops/
https://www.blackhat.com/us-17/training/dark-side-ops-custom-penetration-testing.html

A really good overview of the class is here https://www.ethicalhacker.net/features/root/course-review-dark-side-ops-custom-penetration-testing

I enjoyed the class. This was actually my second time taking the class and it wasn't nearly as overwhelming the 2nd time :-)

I’ll try not to cover what is in Raphael’s article as it is still applicable and I am assuming you read it before continuing on.

I really enjoyed the VisualStudio time and building Slingshot and Throwback myself along with getting a taste for extending the implant by adding the keylogger, mimikatz, and hashdump modules.

Windows API developers may be able to greatly extend slingshot but I don't think I have enough WinAPI kung fu to do it and there wasn’t enough setup around the “how” to consistently do it either unless you have a strong windows API background. However, one of the labs consisted of adding load and run powershell functionality which allows you to make use of the plethora of powershell code out there.

There was also a great lab where we learned how to pivot through a compromised SOHO router and the technique could also be extended for VPS or cloud providers.

Cons of the class.

The visual studio piece can get overwhelming but it definitely gives you a big taste of (Windows) implant development. The class material are getting slightly dated in some cases. A refresh might be helpful. More Throwback usage & development would be fun (even as optional labs).

DSO II
https://silentbreaksecurity.com/training/dark-side-ops-2-adversary-simulation/
https://www.blackhat.com/us-17/training/dark-side-ops-ii-adversary-simulation.html

Lab one was getting a fresh copy of slingshot back up and running and then setting up some additional code to do a powershell web cradle to get our slingshot implant up and running on a remote host. Similar to how metasploit web delivery does things.

Lab 2 was doing some devops to set up servers, OpenVPN to tunnel traffic, and adding HTTPS to our slingshot codebase.

Lab 3 was some Initial activity labs (HTA and chrome plugin exploitation)

Lab 4 was tweaking our HTA to defeat some common detections and protections. We also worked on code to do sandbox evasions as it’s becoming more common for automated sandbox solutions to be tied to mail gateways or just for people doing response.

Lab 5 whitelist bypassing

Lab 6 was doing some profiling via powershell and using slingshot to be able to do checks on the host

Labs 7-9 building a kernel rootkit

Lab 10 persistence via COM Hijacking and hiding our custom DLL in the registry and Lab 11 was privilege escalation via custom service.

Final Thoughts

I enjoyed the four days and felt like I learned a lot. So the TLDR is that I recommend taking the class(es).

Criticisms:
I think the set of courses are having a bit of an identity crisis mostly due to the 2 day
format and would be a much better class as a 5 day. It is heavy development focused meaning you
spend a lot of time in Visual Studio tweaking C code. The “operations” piece of the course definitely
suffers a bit due to all the dev time. There was minimal talk around lateral movement and the whole
thing is entirely Windows focused so no Linux and no OSX. A suggestion to fix the “ops” piece
would be to have a Dark Side Ops - Dev and Dark Side Ops - Operator courses where the dev one
is solely deving your implant and the Operator course would be solely using the implant you dev’d
(or was provided to you). The Silent Break team definitely knows their stuff and a longer class
format or switch up would allow them to showcase that more efficiently.

Blog Archive

Blogs

Links