Message-ID: <007601cb326c$94d6c130$010000c0@ml>
Date: Mon, 2 Aug 2010 21:00:10 +0300
From: "MustLive" <mustliveua@...il.com>
To: <bugtraq@...urityfocus.com>
Subject: Information Leakage and Full path disclosure vulnerabilities in WordPress

Hello Bugtraq!

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 

Powered by blists - more mailing lists