full-disclosure - Re: WordPress Authenticated File Upload Authorisation Bypass

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 22 Jun 2012 11:00:58 +1200
From: Denis Andzakovic <denis.andzakovic@...urity-assessment.com>
To: Greg Knaddison <greg.knaddison@...uia.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: WordPress Authenticated File Upload
 Authorisation Bypass

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Say a wordpress install has been configured as such that the user
running the web server does not have write access to wp-content/plugins.
A wordpress admin then attempts to upload a plugin, they get prompted
for ftp credentials to be able to install. Wordpress does this to ensure
everything has the right permissions.
(http://codex.wordpress.org/Managing_Plugins#Installing_Plugins)

*Before* getting prompted for these creds, the uploaded file is staged
into the uploads directory, which lives under the web-root. The issue
here is that files, regardless of installation status and type, are
thrown into the uploads directory.

I see one potential scenario as; a sysadmin would lock down the file
permissions on the wp-content/plugins directory to stop Wordpress
users/admins from uploading potentially malicious code. Admittedly,
config define( 'DISALLOW_FILE_MODS', TRUE), is the correct way of doing
this, however that doesn't make the former scenario completely implausible.

Regards,
Denis

On 22/06/12 2:42 AM, Greg Knaddison wrote:
> On Wed, Jun 20, 2012 at 8:04 PM, Denis Andzakovic
<denis.andzakovic@...urity-assessment.com
<mailto:denis.andzakovic@...urity-assessment.com>> wrote:
>
> Exploitation of this vulnerability requires a malicious user with
> access to the admin panel to use the
> "/wp-admin/plugin-install.php?tab=upload" page to upload a malicious
> file.
>
>
> That tool is meant to allow an admin to upload arbitrary php plugins.
You can argue that this feature is insecure by design, but there are two
solutions from the WordPress perspective:
>
> 1) "Don't grant malicious users the permission to install plugins."
> 2) If you don't want this feature on your site at all, this feature can
be disabled in the config define( 'DISALLOW_FILE_MODS', TRUE);
>
> By the way, two more "vulnerabilities" the theme installer has this
same issue and the upgrade tool could also be abused if you can poison
the DNS of the server.
>
> Regards,
> Greg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP46eqAAoJED9OsznShNuRuekH/2zmzIOEkvCK+K8CtS/WgJER
jU/A0nVLUlFpvI5hPo5tx7Ago7TCxXmQbohsy6bHuUBehk2qT8VAPIox4mqs6RQk
9qtuBUBoCCJhiEO+HITpTvrqd4cskTgEY87KzCE6BkbhDq46PCNwSckceBIruEY7
PPkNCkabNXgyRQj6uvJqlg8eoe4FfXDujFBcTxVcWZEciJAxYDVGUe7V3mkekmZ2
E7ixd5tCNs9sZ60LUQ5huj4and5JaBFHiQTj8pwJ73yuFoFwoNwtFSBZ7r8qGzjl
J99IxBfgP/pDcioEi43j9CBfIJTElgwhH3guu4FneiGa5lEKwdirPBgEI9LKYA8=
=bQkR
-----END PGP SIGNATURE-----

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/