Re: Information Leakage and Full path disclosure vulnerabilities in WordPress

[Henri Salo <henri () nerv fi>]

On Mon, 2 Aug 2010 21:00:41 +0300
"MustLive" <mustliveua () gmail com> wrote:

> Hello Full-Disclosure!
>
> I want to warn you about security vulnerabilities in WordPress which I
> published at 30.07.2010 during my Day of bugs in WordPress 2 project.
>
> ------------------------------
> Advisory: Day of bugs in WordPress 2: Information Leakage and Full
> path disclosure vulnerabilities in WordPress
> ------------------------------
> URL: http://websecurity.com.ua/4419/
> ------------------------------
>
> These are Information Leakage and Full path disclosure
> vulnerabilities which I found at 05.06.2007. They are concerning
> WordPress Database Backup plugin which was a part of WordPress 2.0.x
> (was core plugin).
>
> ------------------------------
> 1. Information Leakage.
> ------------------------------
>
> Access to backups of DB of site on WordPress is possible in plugin
> WordPress Database Backup (WP-DB-Backup) via guessing of full path to
> them. The backups can be created by admin or automatically. For the
> attack it's needed that backups were saving at the site (at least for
> some time). WP-DB-Backup - it's popular plugin (which shipped with
> WordPress 2.0.x), which only from the site wordpress.org was
> downloaded 546218 times (at the state of 30.07.2010).
>
> Affected products: WordPress 2.0.11 and previous versions, with which
> plugin WordPress Database Backup was shipped, and also all versions
> of WordPress (2.9.2 and previous versions) at using of this plugin
> (officially it compatible with WP 2.9.2 and previous versions and
> potentially can work with WP 3.0 and 3.0.1).
>
> Full path to the file with backup is the next:
>
> http://site/wp-content/backup-xxxxx/database_wp_20070605_704.sql.gz
>
> To get to backup it's needed to reveal folder name and file name. At
> that they can be revealed separately - first reveal folder and
> already then file.
>
> 1. Folder name (backup-xxxxx) - it's "backup-" + 5 chars of
> md5-alphabet and it's 1048576 combination.
>
> 2. File name - it's name of site's database in MySQL (database) + "_"
> + prefix (wp) + "_" + date of backup creation in format YYYYMMDD
> (20070605) + "_" + number from 000 to 999 (704) + ".sql.gz".
>
> Name of database can concur with domain or with folder at the server,
> where the site is placed (providers often do so), so for revealing of
> database name it's possible to use Full path disclosure vulnerability
> (there are a lot of them in WP).
>
> Prefix by default equal "wp". If prefix is non-standard, then it's
> possible to find it with help of other vulnerabilities in WP,
> particularly SQL DB Structure Extraction (which I wrote about
> earlier).
>
> This number from 000 to 999 - it's Swatch Internet time and it's 1000
> combinations. If to know exact time of creating of the backup file,
> e.g. at CSRF-attack (which I'll tell about), then it's possible to
> determine this number. For example, if the file was created at
> 12:00:00 at the server, then this number will be equal 500.
>
> So in common case, when name of database, prefix and date are known,
> it'll have to do up to 1048576 combinations (folder) + up to 1000
> combinations (file) = up to 1049576 combinations (full path to the
> file). On average it's 524788 combinations, which can be picked up
> quickly enough with fast Internet connection.
>
> ------------------------------
> Protection against this vulnerability.
> ------------------------------
>
> For protection it's needed to use appropriate file .htaccess. And
> placed it e.g. in folder wp-content, for denial of download of
> backups from the folder with backups. Which I'm using from the time
> when found this vulnerability.
>
> It can be bypassed with help of Arbitrary file deletion vulnerability
> (http://websecurity.com.ua/1676/), which I wrote about in December
> 2007 (CVE-2008-0194). To use it it's needed to conduct CSRF-attack on
> admin. This attack will work in WP-DB-Backup <= 2.0.
>
> http://site/wp-admin/edit.php?page=wp-db-backup.php&backup=.htaccess
>
> If to place .htaccess in folder with backups, then it can be deleted.
> Even with fixed Directory Traversal - in the folder with backups the
> files can be deleted in any case. So it's needed to place .htaccess
> not in the folder with backups, but in higher level folders, e.g. in
> folder wp-content.
>
> Taking into account that WordPress Database Backup plugin creates
> empty index.php in the folder with backups for protecting from
> leaking of information about backups, then with help of Arbitrary
> file deletion vulnerability (at CSRF-attack on admin) it can be
> bypassed:
>
> http://site/wp-admin/edit.php?page=wp-db-backup.php&backup=index.php
>
> Then it'll be no need to guess file name. It'll work in all versions
> of WordPress with this plugin (WP-DB-Backup <= 2.0).
>
> And if Directory Traversal hole isn't fixed, then it's possible to
> speed up process of finding of the folder with backups (backup-xxxxx)
> with help of Arbitrary file deletion vulnerability (at CSRF-attack on
> admin), and to delete index.php in folder wp-content:
>
> For WordPress <= 2.0.3 (WP-DB-Backup <= 1.7):
>
> http://site/wp-admin/edit.php?page=wp-db-backup.php&backup=../index.php
>
> If backups are creating regularly (every day), or certainly known the
> date of creating of backup, then it's possible to easily get it.
> Otherwise, it's possible to guess names of backup files. Or it's
> possible to conduct CSRF-attack on admin and create backup, which
> I'll tell about in the next advisory.
>
> This leakage of information in backup of DB is the most dangerous
> concerning with that there are login and hash of admin in backup.
> Which can be used for gaining access to the site. It was very actual
> before releasing of WordPress 2.5, in which authorization system was
> remade, after Steven Murdoch drew attention of WP developers at
> Cookie Authentication vulnerability in WordPress
> (http://securityvulns.ru/Sdocument460.html). And from version 2.5 in
> WP new authorization method via cookies is using, but even in new
> versions of engine the leakage of backups is still dangerous and it's
> better not to allow it.
>
> ------------------------------
> 2. Full path disclosure.
> ------------------------------
>
> There are two Full path disclosure vulnerabilities in WP-DB-Backup,
> which appear at appropriate POST requests. They are working only if
> user has appropriate rights (admin in particular).
>
> http://websecurity.com.ua/uploads/2010/WordPress%20Database%20Backup%20Full%20path%20disclosure.html
>
> http://websecurity.com.ua/uploads/2010/WordPress%20Database%20Backup%20Full%20path%20disclosure2.html
>
> Affected products: these vulnerabilities works in plugin WordPress
> Database Backup 2.0 and previous versions in any versions of
> WordPress.
>
> ------------------------------
> Protection against these vulnerabilities.
> ------------------------------
>
> For protection it's possible to fix these Full path disclosure
> vulnerabilities by yourself (as others FPD in WordPress), or update
> plugin to last version WP-DB-Backup 2.2.2.
>
> With WordPress 2.0.11 the version 1.8 of plugin is shipped. As I
> checked recently, Full path disclosure and other vulnerabilities were
> fixed in version 2.1 of the plugin. So the last version of the plugin
> WordPress Database Backup 2.2.2 isn't vulnerable to CSRF and Full
> path disclosure (and isn't vulnerable to above-mentioned Directory
> Traversal, Arbitrary file deletion, DoS and XSS
> (http://websecurity.com.ua/1676/)). But the last version of the
> plugin is still vulnerable to Information Leakage.
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua 

Have you contacted WordPress and/or requested CVE-identifiers for these
issues?

Best regards,
Henri Salo

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