On Mon, 2 Aug 2010 21:00:41 +0300 "MustLive" <[email protected]> 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/
