('binary' encoding is not supported, stored as-is) In-Reply-To: <20020926160908.GA21760at_private> >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
This archive was generated by hypermail 2b30 : Thu Oct 03 2002 - 19:47:31 PDT