Re: Postnuke XSS issues [correction]

[Brian E <brian_erdelyi () yahoo com>]

In-Reply-To: <20020926160908.GA21760 () stateful net>

> As it turns out the Postnuke issue in particular is a red herring.
>
> As the lead developer describes it -- the cookie generated is a local
> site cookie that is sandboxed within the confines of the
> browser/session.
>
> It is not the remote user's cookie.

The correction posted here on BugTraq is false.  The vulnerability exists 
with PostNuke .72.  I expect this exists for previous versions as well but 
have not tested. 

I have used the sample exploit URL against my own PN .72 system. 

1.  Close all instances of IE. 
2.  Use the url against my site.  The session ID is displayed in the popup 
(the script is embeded in the the HTML source). 
3.  View my site database in MySQL.  NUKE_SESSION_INFO table contains an 
active session ID (pn_sessid field).  No user is associated with this 
session ID (i.e. pn_uid=0). 
4.  Logon to my site.  Provide a userid and password.
5.  View my site database in MySQL.  NUKE_SESSION_INFO table contains an 
active session ID (as displayed in #3).  The userid I used to logon to my 
site (from #4) is now associated with this session ID. 
5.  Use the url against my site.  The session ID is displayed in the popup 
(the script is embeded in the HTML source).  This is the same session ID 
displayed in #1 and represents the authentication token for the user (user 
account used in #4).  An attacker who successfully obtains this 
information could hijack the valid session and assume the identity and 
privileges of the user from #4. 

This process has been simplified and does not reflect multiple instances 
of IE (which could have unique or shared session ID's). 

Yes, PN may use a sandbox environment if the user has not logged into the 
site yet.  However, if the user logs on before or after this vulnerability 
is exploited it becomes more serious. 

1.  If an attacker obtains (and explots) a valid session ID of a regular 
user, the damage caused to the site would would likely be minimal.  
However, the user may experiance embarassment or some loss of reputation 
as someone could have impersonated them and posted comments as the user. 
2.  If an attacker obtains (and exploits) a valids session ID of a 
postnuke moderator or other privileged user (i.e. postnuke admin), the 
damage caused to the site would be greater than #1.  This user may be able 
to alter the configuration of the postnuke application or affect data that 
appears on the site to other users.  This would not allow direct access to 
the MySQL database or file system.  Damage to user is same as #1. 

A postnuke admin can protect the site by timing out session ID's when no 
longer in use. 

A user can protect themself by logging out of the application, don't just 
close the browser. 

I would also argue that if a user's actions are not monitored, they will 
go undetected.  Will a driver run through a red light if they are stopped 
on a deserted road with no one around?  What about if that driver see's 
they are being watched by a camera?  Yes, the web server may be logging 
requests but these records do not easily or directly show what action a 
particular user performed.  In my opinion, individual user accountability 
in PostNuke is not achieved.  Knowing that actions may go undetected, a 
user may be further tempted to try exploiting vulnerabilities. 


Regards, 
Brian, CISSP