('binary' encoding is not supported, stored as-is) In-Reply-To: <20020926160908.GA21760stateful.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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]